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Preface 


This  research  was  part  of  an  effort  to  develop  a  technology  which  will  allow  sophis¬ 
ticated  end-users  to  formally  specify  and  compose  software  applications  using  domain- 
oriented,  rather  than  programming-oriented,  terms.  Ultimately,  such  a  technology  will 
enable  users  to  compose  applications  to  suit  their  requirements,  to  execute  prototypes  of 
these  composed  applications  to  verify  that  they  behave  as  expected/desired  and,  then,  to 
automatically  generate  efficient  software  code  to  satisfy  the  original  requirements.  This 
thesis  investigated  the  role  of  software  architectures  in  the  development  of  such  an  appli¬ 
cation  composition  system  which  has  been  named  Architect.  I  hope  that  the  Architect 
system  implemented  herein  wiU  prove  to  be  a  useful  starting  point  in  achieving  the  overall 
research  goal  of  developing  a  fuU-scale  application  generation  system. 

I  wish  to  thank  my  committee  members.  Majors  Gregg  Gunsch  and  Dave  Luginbuhl, 
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Abstract 

This  research  investigated  technology  which  enables  sophisticated  users  to  specify, 
generate,  and  maintain  application  software  in  domain-oriented  terms.  To  realize  this  new 
technology,  a  development  environment,  called  Architect,  was  designed  and  implemented. 
Using  canonical  formal  specifications  of  domain  objects.  Architect  rapidly  composes  these 
specifications  into  a  software  application  and  executes  a  prototype  of  that  application  as 
a  means  to  demonstrate  its  correctness  before  any  programming  language  specific  code 
is  generated.  Architect  depends  upon  the  existence  of  a  formal  object  base  (or  domain 
model)  which  was  investigated  by  another  student  in  related  research.  The  research  de¬ 
scribed  in  this  thesis  relied  on  the  concept  of  a  software  architecture,  which  was  a  key 
to  Architect’s  successful  implementation.  Various  software  architectures  were  evaluated 
and  the  Object-Connection-Update  (OCU)  model,  developed  by  the  Software  Engineering 
Institute,  was  selected.  The  Software  Refinery  environment  was  used  to  implement  the 
composition  process  which  encompasses  connecting  specified  domain  objects  into  a  com¬ 
posed  application,  performing  semantic  analysis  on  the  composed  application,  and,  if  no 
errors  are  discovered,  simulating  the  execution  of  the  application.  Architect  was  validated 
using  both  artificial  and  realistic  domains  and  was  found  to  be  a  solid  foundation  upon 
which  to  build  a  full-scale  application  composition  system. 
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CREATING  AND  MANIPULATING  FORMALIZED  SOFTWARE 
ARCHITECTURES  TO  SUPPORT  A  DOMAIN-ORIENTED 
APPLICATION  COMPOSITION  SYSTEM 


I.  Introduction 


1.1  Background 

A  “software  crisis”  is  upon  us,  characterized  by  expensive,  often  late,  often  unreliable 
and  difficult  to  maintain  systems  which  seldom  meet  all  their  requirements  (6:7-8).  As 
computer  hardware  becomes  more  powerful  and  significantly  less  expensive,  it  becomes 
possible  to  find  automated  solutions  to  more  and  more  problems  (6:8).  These  formerly 
marginal  application  areas  often  require  very  large,  very  complex  software  systems  and 
“software  entities  are  more  complex  for  their  size  than  perhaps  any  other  human  con¬ 
struct;...  many  of  the  classical  problems  of  developing  software  products  derive  from  this 
essential  complexity  and  its  non-linear  increases  with  size”  (9:11).  As  if  this  weren’t  bad 
enough,  trends  indicate  a  wideidng  gap  between  the  productivity  of  an  insufficient  number 
of  computer  professionals  and  the  demand  for  their  services,  as  illustrated  in  Figure  1.1 
(6:10).  Clearly,  something  must  be  done  to  improve  quality  and  increase  productivity  in 
the  software  development  process. 

One  technique  touted  to  achieve  these  quality  and  productivity  improvements  is 
software  reuse.  In  terms  of  the  software  development  process,  “reuse  is  very  simply  any 
procedure  that  produces  (or  helps  produce)  a  system  by  reusing  something  from  a  previous 
development  effort”  (15:2).  But  to  obtain  its  maximum  benefits,  software  reuse  should  be 
a  “process  of  reusing  software  that  was  designed  to  be  reused”  (3:ix).  This  distinction  is 
important  as  it  implies  a  more  systematic,  formal  approach  whose  primary  objective  is 
to  create  reusable  software  components,  not  develop  them  as  an  accidental  by-product. 
Systematic  reuse,  most  notably  design  reuse,  offers  the  promise  of  decreasing  overall  soft- 
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Figure  1.1.  Software  Development  Trends 

ware  development  costs,  improving  maintainability,  increasing  understandability,  reducing 
complexity  and  improving  reliability  (17). 

Traditional  engineering  disciplines  have  long  recognized  and  successfully  employed 
reuse  of  design  products.  They  benefit  from  large  bodies  of  scientific  knowledge,  which  over 
the  years,  have  been  codified  into  models  (12).  These  models  act  as  reusable  templates  from 
which  to  construct  practical,  working  solutions  to  problems  in  a  specific  engineering  area. 
For  example,  “automotive  engineers  have  models  of  cars,  civil  engineers  have  models  of 
bridges,  mechanical  engineers  have  models  of  rolling  mills,  electrical  engineers  have  models 
of  motors...”  (12:140).  The  engineer  is  trained  to  understand  these  models,  to  recognize 
which  model  will  solve  a  particular  problem,  and  to  adapt  the  model,  if  necessary,  to  fit 
a  specific  application.  He  also  knows  that  proper  usage  of  the  appropriate  model  will 
produce  the  desired  result  even  before  he  attempts  to  build  the  actual  object. 

Software  engineering  is  a  relatively  new  discipline  which  is  just  now  beginning  to 
codify  its  body  of  knowledge.  Unlike  other  engineering  disciplines,  it  does  not  currently 
rely  on  models  as  a  means  of  designing  working  solutions.  Instead,  each  new  problem  is 
treated  in  isolation,  as  a  unique  situation  requiring  a  completely  unique  solution.  D’Ippolito 
maintains  that  “models  can  do  for  the  software  industry  what  they  have  done  before  and 
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continue  to  do  for  the  main-line  engineering  professions”  ( 1 1:258).  That  is,  they  can  provide 
“reuse  at  the  design  level,  reduced  system  complexity,  a  means  to  measure  project  risk, 
reduced  coding  costs,  reduced  testing  costs,  reduced  documentation  costs,  and  increased 
maintainability  and  enhanceability”  (11:258). 

We  can  think  of  a  model  as  an  architecture  or  a  blueprint  for  building  something. 
When  computer  scientists  discuss  computer  hardware,  they  implicitly  or  explicitly  refer¬ 
ence  its  structural  composition,  its  schematic  diagram,  its  architecture.  The  concept  of  an 
architecture  for  computer  hardware  is  clearly  understood  in  the  computer  science  commu¬ 
nity;  the  term  is  now  being  applied  to  computer  software  as  well.  A  software  architecture 
is  “the  high-level  packaging  structure  of  functions  and  data,  their  interfaces  and  control,  to 
support  the  implementation  of  applications  in  a  domain”  (20:3).  More  simply,  it  describes 
the  components  which  constitute  a  software  system  and  how  those  components  are  con¬ 
nected  (a  more  precise  definition  of  the  term  “component”  will  be  presented  in  Chapter 
3).  If  the  needed  components  already  existed  in  a  library  and  if  the  appropriate  compo¬ 
nents  could  be  easily  identified,  retrieved,  and  connected,  reliable  software  systems  could 
be  designed  and  implemented  very  quickly. 

The  Software  Architectures  Engineering  (SAE)  Project  at  the  Software  Engineering 
Institute,  an  affiliate  of  Carnegie-Mellon  University,  is  researching  the  feasibility  of  such 
a  process,  which  they  have  named  “model-based  software  development”  (24).  In  this 
context,  a  model  may  be  thought  of  as  a  set  of  software  components  or  modules,  each 
performing  a  well-defined  operation  or  function.  In  traditional  engineering  disciplines, 
the  models  and  the  rules  for  combining  them  are  stored  in  public  technology  bases  where 
they  are  readily  available  to  anyone  who  wants  to  use  them  (24:7).  The  SAE  project 
seeks  to  develop  such  a  technology  or  knowledge  base  for  various  software  application 
areas  and  domains.  Developers  of  new  software  systems  in  these  specific  domains  will 
be  able  to  choose  appropriate  components  from  the  knowledge  base  and  combine  those 
components  using  appropriate  connection  rules  (also  in  the  knowledge  base)  to  create  a 
software  architecture  which  represents  the  desired  software  system. 
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1.2  Problem 


As  in  the  traditional  engineering  disciplines  (where,  for  example,  automotive  engi¬ 
neers  design  automobiles,  not  bridges  or  airplanes),  model-based  software  development  is 
likely  to  be  conducted  within  a  particular  domain  or  application  area.  To  make  it  a  real¬ 
ity,  there  must  be  a  set  of  readily- available  software  components,  a  way  for  the  software 
developer  to  quickly  and  easily  select  the  components  required  to  construct  his  particular 
application,  and  a  means  to  compose  those  components  in  a  meaningful  way  to  produce 
the  desired  application.  An  obvious  approach  to  this  problem  would  be  to  develop  an 
automated  system  to  assist  in  this  process.  To  do  so. 


•  there  must  be  a  formal  description  (both  in  human-  and  machine-understandable 
terms)  of  the  available  components, 

•  there  must  be  a  formal  definition  of  the  software  architecture  or  framework  into  which 
the  components  can  be  placed,  and 

•  there  must  be  a  method  by  which  the  software  developer  can  specify  the  application 
that  he  wants  to  create. 

Figure  1.2  provides  a  simplified  illustration  of  a  domain-specific  application  compo¬ 
sition  system.  A  domain  analysis,  conducted  by  experts  in  the  application  area,  provides 
the  basis  for  identifying  and  constructing  a  set  of  appropriate  domain-specific  compo¬ 
nents.  A  generalized  software  architecture  provides  the  basis  for  developing  an  architec¬ 
ture  customized  for  the  domain.  A  domain-specific  language  allows  the  software  developer 
to  specify,  in  domain-oriented  terms,  the  desired  application  which  is  constructed  using 
the  domain-specific  architecture  and  appropriate  domain  components  from  the  technology 
base. 


1.2.1  Problem  Statement 


Develop  a  formalized  model  of  a  software  architecture  and  implement  it  within 
a  domain-specific  application  composition  system. 
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1.3  Scope 

This  research  effort  focuses  on  formalizing  an  appropriate  software  architecture  and 
implementing  it  within  a  domain-specific  application  composition  system.  The  implemen¬ 
tation  will  enforce  the  rules  of  composition  established  by  the  software  architecture  model 
and  simulate  the  behavior  of  the  composed  application,  using  formal  specification  technol¬ 
ogy.  This  enables  the  developer  to  verify  that  the  system  behaves  as  intended  before  it  is 
actually  coded  (with  automated  assistance)  in  an  implementation  language  such  as  Ada. 

There  are  many  additional  elements  of  a  useful  and  usable  application  composition 
system;  several  related  research  eflForts  are  currently  underway  at  the  Air  Force  Institute  of 
Technology  to  address  them.  Most  notably,  Captain  Mary  Anne  Randour  has  developed  a 
language  with  which  the  software  developer  can  formally  specify  his  application  in  domain- 
oriented  (rather  than  programming-oriented)  terms  (33)  and  Lieutenant  Timothy  Weide 
is  developing  a  visual  interface  to  facilitate  application  specification  and  composition  (44). 

1.4  Sequence  of  Presentation 

The  remainder  of  this  thesis  is  organized  as  follows: 

Chapter  II  provides  a  review  of  the  available  literature  concerning  software  architec¬ 
tures. 

Chapter  III  describes  the  application  composition  system  of  which  this  thesis  effort 
is  a  part.  It  serves  as  a  requirements  analysis. 

Chapter  FV  presents  an  overview  of  the  design  of  the  application  composition  system 
introduced  in  Chapter  III  and  discusses  the  specific  software  architectural  model  which 
was  used  as  its  foundation. 

Chapter  V  explains  the  detailed  design  of  the  application  composer  implemented 
during  this  research  effort. 

Chapter  VI  demonstrates  how  the  application  composer  was  used  to  compose  mean¬ 
ingful  applications  within  a  specific  domain. 
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Chapter  VII  contains  conclusions  about  the  work  described  herein  and  presents  rec¬ 
ommendations  for  further  research. 

Several  appendices  provide  additional  information  for  the  interested  reader. 

Appendix  A  serves  as  a  primer  for  formally  describing  architectural  components. 

Appendix  B  summarizes  detailed,  background  knowledge  about  executing  the  appli¬ 
cation  composer  which  may  be  needed  by  follow-on  researchers  as  they  strive  to  extend 
the  system. 

Appendix  C  displays  sample  composed  applications  for  the  domain  discussed  in 
Chapter  VI. 

Appendix  D  contains  the  application  composer’s  domain-independent  source  code. 

Appendix  E  contains  the  domain-specific  technology  base  for  the  system’s  validating 
domain. 
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II.  Survey  of  Current  Literature 


2.1  Introduction 

“Architecture”  is  a  common  and  well-understood  term  when  applied  to  computer 
hardware.  Even  people  who  are  newly  acquainted  with  computer  science  have  assimilated 
the  concept  of  a  computer  architecture  with  a  mental  image  of  boxes  representing  the  CPU, 
main  memory,  I/O  devices,  etc.,  connected  by  data  and  address  buses.  When  computer 
scientists  discuss  computer  hardware,  they  implicitly  or  explicitly  reference  its  structural 
composition,  its  schematic  diagram,  its  architecture.  To  them,  the  term  “architecture” 
is  synonymous  with  structure,  organization,  and  how  components  are  connected  together. 
Now  the  term  is  being  used  to  describe  software  as  well. 

This  chapter  surveys  software  architectures  in  the  literature.  What  are  they?  How 
are  they  developed?  How  have  they  been  successfully  used?  This  survey  is  not  limited  to 
a  particular  time  period,  although  serious  interest  in  the  topic  appears  to  have  begun  in 
the  mid  1980s. 

2.2  Description  of  Software  Architectures 

The  American  Heritage  Dictionary  defines  architecture  as  “a  style  and  method  of 
design  and  construction.”  In  Model-Based  Software  Development,  an  architecture  is  “a 
selection,  from  a  technology  base,  of  models  and  composition  rules  that  defines  the  struc¬ 
ture,  performance,  and  use  of  a  system  relative  to  a  set  of  engineering  goals”  (24:8),  where 
a  model  is  simply  “reusable  engineering  experience”  (24:2).  Kang  defines  a  software  archi¬ 
tecture  as  “the  high-level  packaging  structure  of  functions  and  data,  their  interfaces  and 
control,  to  support  the  implementation  of  applications  in  a  domain”  (20:3)  and  a  domain 
as  “a  set  of  current  and  future  applications  which  share  a  set  of  common  capabilities  and 
data”  (20:3).  As  referenced  by  Lane,  Shaw  expands  the  concept  of  a  software  architecture 
with  this  definition:  “the  study  of  large  scale  structure  and  performance  of  software  sys¬ 
tems”  (22:1).  Clearly,  all  these  definitions  have  “structure”  in  common;  in  its  most  general 
form,  then,  a  software  architecture  somehow  represents  the  structure  of  a  software  system. 
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It  is  human  nature  to  be  confused  and  uncomfortable  with  complexity.  Developing 
ever  larger  and  more  complex  software  systems  leads  to  problems  describing  the  system- 
level  design;  i.e.,  the  kinds  of  modules  used  in  the  system  and  how  those  modules  are 
connected.  This  system-level  design  or  software  architecture  level  “requires  new  kinds 
of  abstractions  that  capture  essential  properties  of  the  major  subsystems  and  the  ways 
they  interact”  (38:143).  Abstraction  is  a  process  which  allows  us  to  reduce  or  manage 
complexity,  extracting  only  essential  elements  or  qualities  from  the  actual  physical  object 
or  concept  and  ignoring  non-essential  details.  Software  architectures  provide  a  means  for 
describing  these  abstractions. 

There  are  many  similarities  in  the  way  existing  software  systems  are  organized  or 
structured.  These  common  architectures  can  be  grouped  into  the  following  broad  categories 
(38:143-4): 

1.  Pipes  and  Filters:  Each  module  receives  inputs  and  transforms  those  inputs  in  some 
meaningful  way  into  outputs,  which  then  become  the  inputs  of  another  module.  Mod¬ 
ules  are  connected  when  the  output  of  one  modiile  serves  as  the  input  to  another. 


stream 


Filter 


j  stream  ^  | 
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Figure  2.1.  Filters  and  Pipes 
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2.  Data  Abstraction:  Each  module  represents  an  object  and  its  associated  operations. 
The  connections  in  this  type  of  architecture  represent  one  object  invoking  another 
object’s  operation.  This  approach  is  also  known  as  object-oriented  design. 


Figure  2.2.  Data  Abstraction 


3.  Layered  Systems:  The  system  is  organized  hierarchically,  with  each  layer  providing 
services  to  the  layer  above,  while  receiving  services  from  the  layer  below.  This  is  a 
common  architecture  for  operating  systems. 


Users 

Figure  2.3.  Layered  Systems 
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4.  Rule-Based  Systems;  A  computational  mechanism  sequentially  applies  a  collection 
of  applicable  rules  from  a  knowledge  base.  Each  rule  specifies  the  condition  under 
which  it  can  be  executed  and  the  action  that  will  be  taken  when  it  does  execute. 


Knowledge  Base 


Figure  2.4.  Rule-Based  Systems 


5.  Blackboard  Systems:  A  central  data  structure  (representing  the  state  of  the  compu¬ 
tation)  is  surrounded  by  independent  processes  which  check  its  status  and  execute  if 
they  can  further  the  calculation  and/or  enable  another  process  to  execute. 


Figure  2.5.  Blackboard  Systems 


Although  these  basic  architectures  provide  meaningful  abstractions  to  help  us  grasp 
how  systems  are  structured  and  can  be  used  to  describe  a  wide  variety  of  software  systems, 
they  are  currently  used  only  informally,  are  not  widely  understood,  and  are  not  systemati¬ 
cally  taught  to  computer  professionals  (38:144).  This  is  unfortunate  because  architectural 
analysis  can  support  reuse  of  software  development  products  by  focusing  attention  on  the 
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high-level  design  or  system  framework  and  by  increasing  understanding  of  the  relationship 
between  system  organization  and  system  behavior  (29:125).  To  obtain  the  majdmum  ben¬ 
efits  offered  by  software  architectures,  certain  information  about  components  and  connec¬ 
tions  must  be  available.  Such  information  includes  informal  descriptions,  abstract  models, 
syntax,  semantics,  evaluation  criteria,  engineering  considerations,  etc.  (38:145).  Difficul¬ 
ties  in  identifying,  codifying  and  disseminating  this  architectural  information  nave  kept 
software  architectures  from  being  used  more  extensively  (38:145). 

2.3  Developing  Software  Architectures 

In  1988,  Shaw  wrote:  “identifying  and  classifying  system  functions  that  are  common 
to  many  applications  is  a  significant  first  step  to  the  development  of  software  architectures” 
(38:145).  However,  by  1990,  she  had  come  to  agree  with  other  researchers  (1,  17,  43)  that 
domain-specific  architectures  would  likely  lead  to  more  reuse  and  now  feels  that  we  must 
start  by  identifying  and  classifying  system  functions  that  are  common  to  a  particular 
domain  (29:123). 

One  approach  to  identifying  system  functions  is  domain  analysis.  Arango  quotes 
Neighbors:  “a  domain  analysis  is  an  attempt  to  identify  the  objects,  operations  and  re¬ 
lationships  between  what  domain  experts  perceive  to  be  important  about  the  domain” 
(1:153).  Arango  divides  domain  analysis  into  two  phases  (1:153); 


1.  Conceptual  analysis  -  the  identification  and  acquisition  of  information  needed  to 
specify  the  system. 

2.  Constructive  analysis  -  the  identification  and  acquisition  of  information  needed  to 
implement  the  system. 

Because  most  domains  are  quite  stable,  Arango  advocates  using  “practical  domain 
analysis  methods”  which  incrementally  augment  or  refine  existing  domain  knowledge  based 
on  studies  by  domain  experts  and  analysis  of  documentation  from  similar  existing  systems 
(1:159). 

Feature-oriented  domain  analysis  (FODA)  is  one  approach  to  domain  analysis  whose 
primary  goal  is  to  make  domain  products  reusable  (20:47).  A  domain  model  describes 
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the  problems  within  a  domain  which  can  be  solved  with  software  systems;  it  defines  the 
problem  space  and  is  analogous  to  Arango’s  conceptual  analysis  phase.  A  domain  model 
is  “a  definition  of  the  functions,  objects,  data  and  relationships  of  a  domain”  (20:3).  The 
domain  modeling  component  of  FODA  consists  of  three  activites:  feature  analysis,  entity- 
relationship  modeling  and  functional  analysis  (20:35).  Feature  analysis  identifies  the  fea¬ 
tures  (user-visible  characteristics)  of  the  domain,  then  abstracts  and  formally  describes 
them.  The  entity-relationship  model  captures  and  defines  domain  knowledge  by  identi¬ 
fying  entities  and  their  relationships  and  classifying  these  entities  into  homogenous  sets 
(20:41).  Presumably,  features  map  to  entities  in  some  way.  Finally,  the  functional  analysis 
identifies  commonalities  and  differences  between  applications  within  the  domain  (20:42). 

A  second  aspect  of  FODA  is  the  architectural  model.  It  provides  a  software  solution 
to  the  problems  defined  in  the  domain  modeling  phase  (20:47);  it  defines  the  solution 
space  and  is  analogous  to  Arango’s  constructive  analysis  phase.  Architecture  modeling 
concentrates  on  identifying  the  processes  and  domain-specific  modules  required  to  satisfy 
the  solution  and  allocating  the  features,  functions,  and  data  objects  defined  in  the  domain 
model  to  these  processes  and  modules  (20:47).  For  maximum  flexibility  and  adaptation 
to  future  changes,  a  layered  architecture  is  used  as  it  allows  the  system  to  be  viewed 
from  various  levels  of  abstraction  and  encourages  reuse  at  the  appropriate  level  for  each 
application.  More  productivity  is  achieved  through  reuse  at  the  higher  design  levels  (20:50). 

Classifying  system  functions  or  architectural  components  presents  a  major  challenge. 
To  be  effective,  any  classification  scheme  must  be  consistent  (the  same  item  is  classified 
the  same  way  every  time),  expressive  (able  to  communicate  all  required  information), 
and  understandable  (14:303).  Classification  methods,  which  are  heavily  oriented  toward 
indexing  into  very  large  libraries  include  (14): 


1.  enumerated  classification  -  the  domain  is  divided  into  successively  narrower  classes 
in  a  rigid  tree-structured  hierarchy. 

2.  faceted  classification  -  the  domain  is  divided  into  its  elemental  classes  or  facets. 
Components  in  the  domain  are  described  by  combining  these  basic  classes  in  a  more 
flexible  structure  than  is  possible  with  the  enumerated  scheme. 
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2.4  Examples  of  Software  Architecture  Use 

There  are  several  examples  of  the  successful  application  of  software  architectures. 

2.4.1  US  Army  Information  Systems  Engineering  Command  Softech,  Inc  analyzed 
seven  typical  Combat  Service  Support  systems  for  the  US  Army  to  evaluate  whether  any 
functions  were  common  to  multiple  applications  and  discovered  that  every  application  in¬ 
cluded  an  inventory  management  function  (37:16).  They  constructed  a  generic  architecture 
for  that  function  and  coded  it  using  Ada  language  packages,  tailoring  the  packages  to  each 
application,  as  necessary.  Although  the  applications  differed  significantly  (i.e.,  personnel, 
logistics,  etc.),  the  generic  architecture  allowed  the  inventory  function  to  be  treated  as  a 
single  entity  and  to  be  reused  across  seven  application  areas.  This  study  demonstrated  the 
feasibility  of  reusing  software  components  and,  to  some  extent,  higher-level  designs  across 
several  different  application  areas  (37). 

2.4.2  Object-Oriented  Design  (OOD)  Paradigm  The  Software  Engineering  Insti¬ 
tute,  while  working  on  the  Ada  Simulator  Validation  Program,  has  developed  a  model  or 
architecture  for  a  flight  simulator  (23).  Each  real-world  component  of  an  airplane  (engine, 
electrical  system,  fuel  system,  etc.)  is  represented  as  an  object  and  encapsulated  as  a  sys¬ 
tem.  Communication  among  the  systems  is  accomplished  via  connection  modules  which 
provide  the  only  interface  between  the  systems  and  their  environment.  See  Figure  2.6. 
The  architecture  provides  a  means  to  systematically  specify  objects,  systems,  and  their 
connections  and  encourages  consistent  implementation  (23:41),  which  results  in  better  un- 
derstandability  and  improved  maintainability.  Although  originally  proposed  as  a  model 
for  a  flight  simulator  only  ,  this  architecture  has  been  used  to  represent  an  elevator  system 
(40),  a  cruise  control  system  (40),  and  an  electrical  system  (7),  among  others. 

2.4.3  Feature-Oriented  Domain  Analysis  (FODA)  Kang  and  others  used  the  com¬ 
plete  FODA  methodology  to  successfully  develop  a  window  management  system  (20). 

2.4.4  Hierarchical  Software  Systems.  A  layered  or  hierarchical  architecture  is  the 
foundation  of  research  conducted  at  the  University  of  Texas.  Analysis  of  two  unrelated 
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OM  =  Otiject_Manager 


Figure  2.6.  OOD  Paradigm  for  a  Flight  Simulator 
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projects  (GENESIS  and  Avoca)  revealed  striking  similarities  in  design  and  organization  (5). 
Based  on  those  similarities,  a  model  was  developed  which  uses  sets  of  “plug-compatible  and 
interchangeable”  (5:3)  components  and  provides  a  straight-forward  means  to  indicate  how 
the  components  are  connected  to  create  a  system  (via  composition  rules  which  provide  the 
“guidelines  by  which  components  can  be  glued  together”  (5:4)).  This  approach  encourages 
component  reuse  and  provides  a  standardized  design  process  which  can  be  used  to  create 
systems  very  quickly;  one  database  management  system  was  designed,  composed  and  im¬ 
plemented  within  20  minutes  (5:2).  Batory  and  O’Malley  assert  that  hierarchical  designs 
can  be  used  for  a  wide  range  of  application  areas  (even  some  real-time,  performance-driven 
applications  where  other  layered  designs  have  resulted  in  slow  implementations  (5:36));  as 
an  example,  their  method  is  currently  being  used  to  design  an  upgrade  to  the  Mach  oper¬ 
ating  system  (5:40). 

2.4.5  Flight  Dynamics  Division  (FDD)  of  the  Goddard  Space  Flight  Center  The 
FDD  has  been  very  successful  using  a  modified  version  of  the  General  Object-Oriented 
Design  (GOOD)  methodology  to  develop  various  simulators.  They  rely  heavily  on  three 
concepts  from  GOOD:  abstraction,  inheritance  and  domain-specific  architectures  (41:278). 
The  Upper  Atmosphere  Research  Satellite  Telemetry  Simulator  (UARSTELS)  benefitted 
from  several  lessons  learned  from  past  development  efforts.  Instead  of  using  a  highly  nested 
architecture  which  was  found  to  greatly  increase  compilation  overhead,  a  non-nested  archi¬ 
tecture  of  Ada  generic  packages  was  used  (41:282).  The  Generic  Dynamics  and  Telemetry 
Simulator  (GENSIM)  used  an  object-oriented  design  and  an  architecture  very  similar  to  the 
SEI  Flight  Simulator  (minus  the  connection  modules).  Significant  lessons  learned  by  FDD 
from  these  projects  include  the  fact  that  high  compilation  overhead  is  caused  by  h'ghly 
nested  architectures,  the  advantage  of  using  an  object-oriented  design  approach,  and  the 
importance  of  building  domain  components  before  developing  an  architecture  (according 
to  the  authors,  this  provides  more  potential  for  reuse  across  multiple  architectures)  (41). 

2.4.6  Command  Center  Processing  and  Display  System  Replacement  (CCPDS-R) 
TRW  used  a  Software  Architecture  Skeleton  (SAS)  to  provide  a  software  structure  which 
“identifies  all  top-level  executable  components,  all  control  interfaces  between  these  compo- 
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nents  and  all  type  definitions  and  data  interfaces  between  these  components”  (36:503).  The 
components  are  part  of  the  Network  Architecture  Services  (NAS)  which  “provides  the  ob¬ 
jects  and  operations  needed  to  construct  robust  real-time  networks  which  support  flexible, 
open  architectures”  (36:501).  The  use  of  SAS  and  NAS  resulted  in  a  “top-level  software 
architecture  definable  in  terms  of  standard  system  building  blocks  with  well-defined  be¬ 
havior  and  interfaces  and  eliminates  a  major  source  of  errors  which  come  in  executive 
logic  control”  (36:502).  “The  ability  to  rapidly  construct  a  working  system  and  focus  on 
real  application  interfaces  rather  than  system  software  inconsistencies  coupled  with  NAS 
extensive  support  software  and  instrumentation  resulted  in  an  extremely  successful  effort” 
(36:514). 

2.5  Conclusion 

Shaw  recognized  that  successful  software  designs  can  be  grouped  into  broad,  general 
categories,  each  representing  a  distinct  software  architecture.  Several  researchers,  including 
Shaw,  are  convinced  that  the  use  of  domain-specific  architectures  will  lead  to  more  reuse 
at  the  design  level  which  should  substantially  increase  reliability  and  reduce  development 
costs  for  new  software  systems.  The  experiences  of  Softech  with  the  U.S.  Army,  the  SEI 
with  their  flight  simxilator  model  and  the  FODA  methodology,  Batory  and  O’Malley’s  hier¬ 
archical  systems,  the  FDD  at  Goddard  Space  Flight  Center  with  the  GOOD  methodology 
and  TRW  with  CCPDS-R  suggest  that  software  architectures  can  facilitate  development 
of  large,  complex  systems. 
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in.  Requirements  Analysis^ 


3. 1  Introduction 

The  wide  availability  of  powerful,  relatively  low-cost  computer  hardware  has  led  to  an 
explosion  in  the  demand  for  computer  software  products  to  automate  a  multitude  of  new 
tasks.  Using  traditional  methods,  computer  scientists  and  programming  professionals  have 
been  unable  to  meet,  in  a  timely  manner,  this  demand  for  the  sophisticated,  large-scale, 
reliable  software  systems  required  for  these  new  applications.  Clearly,  a  new  approach  to 
software  design  and  construction  is  needed. 


Software  engineering  will  evolve  into  a  radically  changed  discipline.  Soft¬ 
ware  will  become  adaptive  and  self-configuring,  enabling  end  users  to  specify, 
modify  and  maintain  their  own  software  within  restricted  contexts.  Software 
engineers  will  deliver  knowledge- based  application  generators  rather  than  un- 
modifiable  application  programs.  These  generators  will  enable  an  end  user 
to  interactively  specify  requirements  in  domain-oriented  terms....  and  then 
automatically  generate  efficient  code  that  implements  these  requirements.  In 
essence,  software  engineers  will  deliver  the  knowledge  for  generating  software 
rather  than  the  software  itself. 

Although  end  users  will  communicate  with  these  software  generators  in 
domain-oriented  terms,  the  foundation  for  the  technology  will  be  formal  repre¬ 
sentations...  Formal  languages  will  become  the  lingua  franca,  enabling  know¬ 
ledge-based  components  to  be  composed  into  larger  systems.  Formal  specifica¬ 
tions  will  be  the  interface  between  interactive  problem  acquisition  components 
and  automatic  program  synthesis  components. 

Software  development  will  evolve  from  an  art  to  a  true  engineering  dis¬ 
cipline.  Software  systems  will  no  longer  be  developed  by  handcrafting  large 
bodies  of  code.  Rather,  as  in  other  engineering  disciplines,  components  will 
be  combined  and  specialized  through  a  chain  of  value-added  enhancements. 
The  final  specializations  will  be  done  by  the  end  user.  KBSE  (Knowledge 
Based  Software  Engineering)  will  not  replace  the  human  software  engineer; 
rather,  it  will  provide  the  means  for  leveraging  human  expertise  and  knowledge 
through  automated  reuse.  New  subdisciplines,  such  as  domain  analysis  and  de¬ 
sign  analysis,  will  emerge  to  formalize  knowledge  for  use  in  KBSE  components. 
(26:629-630) 


'This  chapter  was  co-written  with  Captain  Mary  Anne  Randour.  It  is  included  in  AFIT  Technical 
Report  AFIT/EN/TR-92-5  and  also  appears  in  (33). 
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Perhaps  this  vision  can  become  a  reality  for  selected  domains,  not  just  within  the 
next  century  as  Michael  Lowry  predicts,  but  within  the  next  few  years.  Research  is  cur¬ 
rently  underway  at  the  Air  Force  Institute  of  Technology  (AFIT)  to  achieve  such  a  reality. 
Developing  a  full-scale  application  generation  system,  which  is  capable  of  automatically 
producing  efficient  code  to  satisfy  user-specified  requirements  presented  in  domain-oriented 
terms,  is  a  considerable  task  which  will  require  several  man-years  of  effort.  However,  one 
element  of  application  generation,  the  combining  or  composing  of  required  components  into 
the  proper  framework  or  architecture,  is  attainable  in  the  near  term.  This  chapter  explores 
the  issues  involved  in  developing  such  an  end-user  appbcation  composer  and  describes  one 
possible  methodology  for  accomplishing  it. 

3.2  Operational  Concept 

Several  roles  are  discussed  in  describing  this  new  approach  to  software  development, 
an  approach  where  the  end-user  generates  a  software  application  to  satisfy  his  requirements 
using  the  software  professional’s  knowledge  about  how  to  generate  such  applications.  Some 
of  these  roles  are  new,  others  are  relatively  unchanged  from  those  in  traditional  software 
system  development. 


1.  System  Analyst  -  Specifies  new  systems  in  a  domain  (20:4).  Responsible  for  develop¬ 
ing  the  concept  of  operations  (defining  policy,  strategy,  and  use  of  application)  and 
defining  training  requirements  (10). 

2.  System  Engineer  -  Works  with  the  system  analyst  to  partition  the  system  into  sub¬ 
systems  and  assigns  the  tasks  to  software  or  hardware  development,  as  appropriate 
(2). 

3.  Domain  Engineer  -  Possesses  detailed  knowledge  about  the  domain  and  gathers  all 
the  information  pertinent  to  solving  problems  in  that  domain  (20:4).  Models  the 
real-world  entities  required  to  satisfy  the  poUcy,  strategy,  and  use  of  an  application 
as  defined  by  the  system  analyst.  Determines  how,  if  possible,  these  entities  can  be 
modeled  within  the  constraints  specified  by  the  software  engineer  (10). 

4.  Software  Engineer  -  Designs  new  software  systems  in  the  domain  (20:4).  Responsi¬ 
ble  for  defining  a  formalized  structure  for  the  domain  knowledge  and  providing  the 
translation  from  the  domain-specific  terms  to  executable  software  (10). 

5.  Application  Specialist  -  Uses  systems  in  the  domain  (20:4).  Familiar  with  the  overall 
domain  and  understands  what  the  new  application  must  do  to  meet  the  requirements 
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(a  sophisticated  “user”).  Provides  the  application-specific  information  needed  to 
specify  an  application. 
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Figure  3.1.  Rx)les 


The  relationships  among  these  roles  are  shown  in  Figure  3.1.  Usually,  a  new  sys¬ 
tem  begins  with  the  identification  of  a  new  requirement.  This  requirement,  if  valid,  is 
forwarded  to  a  system  analyst  who  develops  a  concept  of  operations.  The  system  analyst 
works  closely  with  the  system  engineer  who  partitions  the  system  into  software  and  hard¬ 
ware  subsystems.  The  system  engineer  consults  the  appropriate  domain  engineer  to  define 
which  components  of  his  domain  will  be  needed  for  software  applications  in  the  domain. 
The  domain  engineer  and  the  software  engineer  decide  on  which  components  are  needed 
to  model  the  domain.  The  software  engineer  formalizes  the  domain  knowledge  provided 
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by  the  domain  engineer  into  a  domain  mode!  and  its  technology  base.  The  application 
specialist,  using  the  domain  model  established  by  the  software  and  domain  engineers,  cre¬ 
ates  a  specification  for  an  application.  From  this  specification,  an  automated  application 
composer  generates  a  software  design  which  is  then  input  to  a  code  generation  capability. 

3.3  General  System  Concept 

3.3.1  Overview  An  overview  of  the  application  composition  system’s  components 
and  their  relationships  to  each  other  appears  in  Figure  3.2.  First,  domain  analysis  is  per¬ 
formed,  which  consists  of  gathering  appropriate  domain  knowledge,  formalizing  it  via  a 
domain  modeling  language,  and  storing  it  in  a  domain  model.  The  structure  of  the  do¬ 
main  model  is  determined,  in  part,  by  the  domain  modeling  language  (DML)  chosen.  The 
software  architecture  model,  like  the  DML,  imposes  a  specific  structure  on  the  domain 
model,  on  the  grammar  used  by  the  application  specialist,  and,  ultimately,  on  the  final 
application  specification.  The  domain  model  is  used  to  develop  a  domain-specific  gram¬ 
mar.  Although  it  may  be  transparent  to  the  application  specialist,  he  actually  uses  two 
grammars:  one  to  identify  domain-specific  information  and  one  to  specify  the  architecture 
of  the  application.  The  architecture  grammar  remains  the  same  for  different  dommns;  only 
the  domain-specific  grammar  changes.  Application-specific  data  is  written  using  these  two 
grammars  and  is  converted  into  objects  in  the  structured  object  base  by  the  parser. 

The  populated  structured  object  base  and  information  from  the  technology  base  are 
combined  to  build  an  executable  prototype.  First,  the  application  specialist  performs  se¬ 
mantic  checking  on  the  structured  object  base  to  ensure  all  constraints  on  the  system  have 
been  met.  He  then  executes  the  prototype  to  demonstrate  the  behavior  of  the  proposed 
application.  If  the  prototype  does  not  behave  as  required,  the  application  specialist  can 
change  the  original  input  and  re- parse  it  into  the  structured  object  base.  Using  the  knowl¬ 
edge  encoded  in  the  domain  model  and  the  software  architecture  model,  the  structured 
object  base  is  manipulated  into  a  formal  specification  for  a  domain-specific  software  archi¬ 
tecture  (DSSA).  The  DSSA  is  the  system  design  and  becomes  the  basis  from  which  code 
is  generated.  A  visual  system  provides  a  graphical  representation  of  the  structured  object 
base  and  the  DSSA,  as  well  as  a  means  to  add  to  or  modify  them. 
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The  remainder  of  this  section  describes  the  above  concepts  and  activities  in  more 
detail. 

3.3.2  Developing  a  Formalized  Domain  Model  Before  any  applications  can  be  com¬ 
posed  using  this  proposed  system,  the  domain  must  be  analyzed  and  modeled.  In  the 
software  engineering  context,  a  domain  is  commonly  defined  as  “an  application  area,  a 
field  for  which  software  systems  are  developed”  (31:50)  or  “a  set  of  current  and  future 
applications  which  share  a  set  of  common  capabilities  and  data”  (20:2).  Identifying  the 
boundaries  of  the  domain,  as  well  as  “identifying,  collecting,  organizing,  and  representing 
the  relevant  information  in  a  domain  based  on  the  study  of  existing  systems  and  their 
development  histories,  knowledge  captured  from  domain  experts,  underlying  theory,  and 
‘emerging  technology  within  the  domain”  (20:2-3),  constitutes  domain  analysis.  Domain 
analysis  is  currently  the  subject  of  several  other  research  efforts  and  is  not  directly  ad¬ 
dressed  in  this  project.  However,  it  is  important  to  gather  the  basic  data,  formalize  it,  and 
store  it  in  a  standard  format. 

3.3.2. 1  Domain  Knowledge  Domain  knowledge  is  the  “relevant  knowledge” 
that  results  from  a  thorough  domain  analysis  and  later  evolves  naturally  as  more  experi¬ 
ence  is  gained  solving  problems  in  the  domain  (31:47).  More  specifically,  domain  knowledge 
consists  of:  basic  facts  and  relationships,  problem-solving  heuristics,  domain-specific  data 
types,  and  descriptions  of  processes  to  apply  the  knowledge  (4).  In  the  context  of  this 
project,  domain  knowledge  includes:  descriptions  of  domain-specific  objects  (including 
their  attributes  and  operations),  data  types,  composition  rules,  and  templates  for  com¬ 
monly  used  architectural  fragments. 

3. 3.2.2  Domain  Modeling  Language  An  ajialogy  to  a  domain  modeling  lan¬ 
guage  (DML)  can  be  found  in  the  more  familiar  data  definition  language  of  a  database 
management  system.  A  data  definition  language  describes  the  logical  structure  and  access 
methods  of  a  database  (21),  just  as  our  DML  describes  the  logical  structure  of  a  domain 
model  and  defines  how  the  objects  can  be  accessed.  A  DML  used  to  encode  domain 
knowledge  into  a  domain  model  must  be  able  to  formally  describe: 
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1.  Object  Classes:  Abstractions  of  real-world  entities  of  interest  in  the  domain. 

2.  Operations:  Behavior  of  the  objects  in  the  domain. 

3.  Object  Relationships  and  Constraints:  Rules  for  relating  objects  (and  sets  of  objects) 
to  other  objects,  as  well  as  the  constraints  on  these  relationships.  Examples  include: 

(a)  Communication  Structure:  Message  passing  between/among  domain  classes  and 
operations. 

(b)  Composition  Structure:  Rules  for  combining  domain  object  classes  into  higher- 
level  application  classes  and  operations  into  higher-level  application  operations. 

4.  Exception  Handling:  What  to  do  when  an  error  is  encountered. 

To  be  useful  in  an  automated  system,  the  domain  knowledge  must  be  encoded  into 
a  format  that  the  software  system  can  manipulate.  This  problem  is  analogous  to  encoding 
knowledge  in  an  expert  system,  where  human  knowledge  is  gathered  and  represented  as 
redes  that  allow  a  computer  program  to  utilize  the  information.  Neil  Iscoe  describes  a 
method  for  encoding  domain  knowledge  into  a  domain  model  (see  (19)  for  details).  He 
proposes  using  a  domain  modeling  language  or  a  meta-model  as  the  basic  framework  to 
instantiate  a  domain  model  based  on  some  operational  goal(s)  (reasons  for  which  the  knowl¬ 
edge  will  be  used)  (see  Figure  3.3).  Our  operational  goal  is  to  “use  the  domain  model, 
software  architecture  model,  and  structured  object  base  to  generate  a  software  architec¬ 
ture  for  the  application  problem  to  be  solved  -  to  generate  a  domain-specific  software 
architecture”  (2). 

3. 3. 2. 3  Domain  Model  A  domain  model  is  a  “specific  representation  of  appro¬ 
priate  aspects  of  an  application  domain”  (18:302)  including  functions,  objects,  data,  and 
relationships  (30).  It  is  a  restilt  of  expressing  appropriate  domain  knowledge  (identified  by 
the  domain  engineer)  in  a  domain  modeling  language  with  respect  to  certain  operational 
goals  (18:301-2). 

Several  researchers  (5,  11,  12,  24)  have  indicated  that  software  engineering  must 
become  more  of  an  engineering  discipline  if  we  are  ever  to  reap  the  benefits  of  design  reuse 
(increased  productivity,  improved  reliability,  certifiability,  etc.).  When  designing  specific 
applications,  engineers  use  models,  “codified  bodies  of  scientific  knowledge  and  technology 
presented  in  (re)usable  forms”  (11:256)  which  are  available  to  all  practioners  in  various 


3-7 


Sampltt  OperailiorMi  Goals; 

•  Automatic  Program  Generation 

•  Raveree  Engineering 

•  Decision  Modeling 

•  Automated  Testing 


Figure  3.3.  Domain  Model  Instantiation 


technology  bases.  Reuse  of  these  validated,  commonly-used  models,  which  are  readily 
available  in  various  technology  bases,  allows  the  engineer  to  construct  a  practical,  reliable 
solution  to  the  problem  at  hand. 

Contained  within  our  domain  model  is  such  a  technology  base  which  acts  as  a  repos¬ 
itory  for  our  reusable  models.  In  our  system,  these  models  are  often  referred  to  as  compo¬ 
nents.  Using  an  object-based  perspective,  a  component  can  represent  a  real-world  entity, 
concept  or  abstraction  and  encompasses  all  descriptive  and  state  information  for  that  en¬ 
tity/concept/abstraction  as  weU  as  its  behavior  (what  operations  or  functions  it  performs 
and/or  what  transformations  it  undergoes).  Components  can  be  primitive  domain  objects 
as  described  above  or  a  “packaging”  of  these  objects  whose  structure  is  determined  by 
the  software  architecture  model.  These  packaged  components  will  be  referred  to  as  ar¬ 
chitectural  fragments  since  they  can  be  used  to  build  an  application  architecture.  The 
technology  base  contains  templates  for  generic  components,  rules  for  component  composi¬ 
tion,  and  descriptions  of  primitive  object  behavior.  The  parameters  required  to  instantiate 
these  generic  templates  will  be  specified  by  the  application  specialist. 

Domain  analysis  reveals  common  features  of  the  software  architectures  that  can  be 
used  to  implement  various  specific  applications  within  the  domain.  In  addition,  common 
constraints  are  identified  and  codified  into  rules  used  to  determine  how  software  com- 
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ponents  can  be  legally  combined.  Using  rules  allows  additional  flexibility,  any  specific 
architecture  can  be  built  as  long  as  it  meets  the  criteria  specified  by  the  rules. 

3.3.3  Building  A  Structured  Object  Base  Several  steps  must  be  taken  to  build  the 
structured  object  base.  The  following  system  components  are  essential  to  this  phase. 

3.3.3. 1  Domain-Specific  Language  As  with  our  domain  modeling  language, 
an  analogy  to  a  domain-specific  language  (DSL)  can  be  found  in  a  data  manipulation 
language  from  the  realm  of  database  management  systems.  In  the  database  context,  a 
data  manipidation  language  allows  the  user  of  a  database  to  retrieve,  insert,  delete,  and 
modify  data  stored  in  the  database  (21:13).  In  our  context,  a  DSL  is  a  language  with  syntax 
and  semantics  which  represents  all  valid  objects  and  operations  in  a  particular  domain, 
allowing  modeling  and  specification  of  systems  within  that  domain  (32).  According  to 
James  Neighbors,  a  domain  language  is  a  machine-processable  language  derived  from  a 
domain  model.  It  is  used  to  define  components  and  to  describe  programs  in  each  different 
problem  area  (i.fe.,  domain).  The  objects  and  operations  represent  analysis  information 
about  a  problem  domain  (28).  In  our  research,  a  domain-specific  language  is  defined  as  a 
formal  language  used  to  define  instances  of  objects  and  operations  specific  to  a  domain. 

The  objective  of  our  DSL  is  to  generate  the  structured  object  base  needed  to  specify 
an  application  architecture  within  a  specific  domain.  To  do  so,  it  must  be  able  to: 


1.  Instantiate  objects 

2.  Instantiate  generic  objects 

3.  Instantiate  generic  architectural  fragments 

4.  Compose  the  instantiated  objects  and  architectural  fragments  in  some  meaningful 
way 


The  object  classes  defined  in  the  domain  model  are  merely  templates  or  patterns  to 
be  used  when  constructing  objects;  they  do  not  refer  to  specific,  individual  objects.  The 
first  sentence  type  listed  above  creates  specific  instances  of  the  objects  in  the  object  base. 
These  objects  are  used  in  building  architectural  fragments  or  as  parameters  for  generics. 
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Default  values  can  be  used  for  attributes  so  these  values  need  not  be  entered  through  the 
DSL  every  time  they  are  used. 

Generics,  stored  in  the  technology  base,  provide  templates  for  commonly  used  objects 
and  components;  thus,  the  application  specialist  need  not  start  from  scratch  each  time  he 
wants  to  include  one  of  these  commonly  used  components.  Generics  must  be  instantiated 
before  they  can  be  used.  Instantiation  is  done  by  specifying  which  model  is  to  be  used 
and  providing  specific  instances  and/or  other  data,  as  required.  For  example,  a  generic 
architectural  fragment  may  use  three  objects  of  a  certain  class.  When  this  generic  is 
instantiated,  three  specific  object  instances  of  the  required  class  must  be  given. 

3. 3. 3. 2  Software  Architecture  Model  In  addition  to  identifying  the  objects  to 
be  used  in  generating  a  particular  application,  the  application  specialist  must  indicate  what 
is  to  be  done  with  those  objects;  i.e.,  he  must  identify  the  application  operations.  Domain 
primitive  operations,  associated  with  primitive  objects,  are  available  in  the  technology  base. 
But  how  can  these  primitive  operations  be  assembled  (composed)  into  application-specific 
operations?  What  are  the  rules  for  composing  these  primitive  operations  into  application 
operations?  How  can  these  rules  be  represented  and  implemented? 

Software  architectures  provide  insight  into  software  system  composition.  In  its  most 
fundamental  sense,  an  architecture  is  a  recognizable  style  or  method  of  design  and  con¬ 
struction.  A  software  architecture  ha.s  been  defined  as  “a  template  for  solving  problems 
within  an  application  domain”  (40:2-2)  or  “the  high  level  packaging  structure  of  functions 
and  data,  their  interfaces  and  controls,  to  support  the  implementation  of  applications  in 
a  domain”  (20:3).  It  provides  a  mechanism  for  separating  “the  design  of  (domain)  models 
from  the  design  of  the  software”  (10).  This  separation  of  domain  knowledge  from  software 
engineering  knowledge  allows  each  type  of  engineer  to  concentrate  on  the  issues  relevant  to 
his  own  area  of  experience,  without  becoming  an  expert  in  the  other  discipline.  By  focus¬ 
ing  only  on  the  design  of  the  software,  the  software  engineer  is  able  to  develop  simplified 
packaging  and  control  structures  which  can  be  reused  across  a  wide  variety  of  domains. 

Because  a  software  architecture  serves  as  a  structural  framework  for  software  develop¬ 
ment,  we  can  expect  it  to  provide  a  consistent  representation  of  system  components  as  well 
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as  the  interfaces  between  those  components.  A  standard  representation  ensures  that  each 
component  is  developed  in  the  same  manner,  eliminating  many  implementation  choices  and 
simplifying  the  development  process.  This  standardization  also  results  in  consistent  inter¬ 
faces  between  all  components,  enabling  them  to  be  easily  combined.  This  consistency  of 
component  representation  and  interfaces  should  provide  a  suitable  and  flexible  framework 
for  composing  primitive  operations  into  application-specific  ones. 

3.3.3. 3  Architecture  Grammar  Certain  portions  of  the  application  specialist’s 
input  are  not  dependent  on  any  particular  domain;  rather,  they  depend  on  the  software 
architecture  model.  These  architectural  aspects  of  the  application  can  be  specified  using 
a  grammar  common  to  all  domains,  an  architecture  grammar.  This  grammar  enforces  the 
structure  imposed  by  the  software  architecture  model  by  defining  valid  sentences  for  pack¬ 
aging  the  primitive  domain  objects  into  architectural  fragments  to  define  an  application 
architecture.  These  sentences  will  compose  application  operations  using  domain-specific 
components  described  by  the  domain-specific  grammar  and  other  application  operations. 

3. 3. 3. 4  Parser  After  the  application  specialist  specifies  the  application  com¬ 
ponents  using  the  domain-specific  language  and  architecture  language,  the  input  must  be 
parsed  into  objects  in  the  structured  object  base.  The  parser  generates  specific  object 
instances  whose  initial  states  are  determined  by  the  application  specialist’s  input. 

3. 3. 3. 5  Structured  Object  Base  The  structured  object  base  contains  applica¬ 
tion  specific  information:  specific  instances  of  domain  object  classes  with  all  appropriate 
attribute  values  for  determining  the  object’s  state,  as  well  as  relationships  for  both  do¬ 
main  objects  and  operations.  The  kinds  of  objects  that  might  populate  the  object  base 
and  the  overall  structural  framework  of  those  objects  (the  shape  of  the  abstract  syntax 
trees)  are  established  by  the  domain  and  software  architecture  models.  The  specific  object 
instances  and  the  actual  structure  of  the  object  base  are  determined  by  the  application- 
specific  information  provided  by  the  application  specialist  using  the  DSL  and  architecture 
grammars. 
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3.3.4  Composing  Applications  The  application  composer  generates  the  application 
architecture  specified  by  the  application  specialist.  This  is  accomplished  by  combining  the 
appropriate  instantiated  domain  objects  from  the  structured  object  base  in  accordance 
with  the  domain  composition  rules.  After  the  architecture  is  generated,  its  behavior  can 
be  simulated  to  demonstrate  its  suitability  and  correctness.  It  should  be  noted  that  the 
operations  associated  with  each  object  in  the  technology  base  are  certifiably  correct;  that 
is,  individual  objects  are  guaranteed  to  behave  as  required.  However,  the  specific  objects 
which  are  composed  into  the  application  may  have  been  combined  in  such  a  way  that 
the  composed  application  may  not  behave  as  expected  or  required.  When  the  application 
specialist  is  satisfied  that  the  composed  architecture  is  actually  the  one  desired,  he  can 
generate  a  formal  specification  for  the  architecture  which  can  later  be  used  to  develop  a 
fully  coded  system. 

3.3.4. 1  Semantic  Analysis  After  an  application  is  identified,  the  next  step 
is  to  ensure  that  the  specified  composition  is  appropriate;  i.e.,  that  it  makes  sense  and 
meets  the  constraints  imposed  by  the  composition  rules.  This  step  is  accomplished  via  a 
semantic  analysis  phase.  As  in  programming  language  compilers,  one  aspect  of  semantic 
analysis  is  to  verify  that  a  syntactically  correct  construct,  which  satisfies  the  restrictions 
of  the  grammar  in  which  it  was  written,  is  “legal  and  meaningful”  (13:10).  To  be  legal  and 
meaningful,  the  proposed  application  must  meet  certain  other  composition  restrictions: 
e.g.,  components  must  already  exist  before  they  can  be  used,  an  input  to  one  component 
must  be  produced  as  an  output  from  another  component,  etc.  Another  aspect  of  semantic 
analysis  is  to  use  knowledge  about  domain  objects  and  typical  system  constructions  to 
assist  the  application  specialist  in  choosing  the  components  needed  and  in  combining  them 
appropriately  to  create  applications  which  behave  as  desired.  Errors  identified  during  the 
semantic  analysis  phase  must  be  corrected  before  the  composition  process  can  proceed. 

3. 3.4.2  Execute  A  composed  application  architecture  that  passes  aU  semantic 
analysis  checks  is  legal  and  meaningful,  but  does  it  do  what  the  application  specialist  wants 
it  to  do?  The  execute  component  of  the  application  composer  simulates  the  behavior  of 
the  architecture,  using  object  operations  which  specify  each  component’s  behavior.  This 
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behavior  simulation  may  not  be  efficient  or  robust  enough  to  serve  as  a  full-scale  opera¬ 
tional  system,  but  it  provides  the  application  specialist  timely  feedback  on  the  correctness 
of  the  specified  architecture.  If  the  application  is  incorrect  (i.e.,  it  does  not  behave  as  re¬ 
quired/expected),  the  application  specialist  reassesses  the  components  which  were  used  in 
the  application  and  how  they  were  combined,  creating  a  new  or  editted  application  to  sat¬ 
isfy  his  requirements.  This  ability  to  simulate  execution  behavior  in  this  rapid-prototype 
manner  assures  the  application  specialist  that  the  proposed  application  actually  behaves 
correctly  before  a  formal  specification  and  fully-coded  system  are  generated. 

3.3. 4.3  Generate  Specification  A  legal,  meaningful,  and  correctly  composed 
application  provides  a  software  architecture  which  satisfies  the  application  specialist’s 
requirements  for  a  particular  application.  The  software  architecture  can  be  used  as  a 
blueprint,  template,  or  specification  from  which  to  design  and  implement  a  full-scale,  op¬ 
erational  version  of  the  application.  The  generated  specification  is  intended  to  be  in  a 
formal,  machine-processable  format  which  can  be  used  directly  by  a  code  generation  tool 
to  produce  a  fully-coded  application.  However,  the  specification  format  could  be  tailored 
to  provide  whatever  form  is  appropriate  for  the  using  organization:  graphical,  textual,  etc. 

3.3.5  Extend  Technology  Base  Eventually,  the  technology  base,  which  formalizes 
the  knowledge  about  domain  objects,  will  become  outdated  as  understanding  of  the  do¬ 
main  evolves  and  as  the  domain  itself  adapts  to  accommodate  a  changing  technological 
environment.  Although  the  technology  base  may  appear  to  be  static,  it  must  be  dynamic 
enough  to  accommodate  this  additional  information  as  well  as  higher-level  object  classes 
and  operations,  generic  components  and  architectural  fragments  that  are  developed.  These 
additional  elements  give  added  flexibility  to  the  application  specialist  because  more  pre¬ 
defined  components  are  available  for  future  applications 

A  specialized  set  of  tools  allows  the  technology  base  to  be  modified  or  extended 
to  include  this  additional  or  revised  domain  knowledge.  The  extender  must  enforce  the 
structure  dictated  by  the  domain  modeling  language  and  the  software  architecture  model. 
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3.3.6  Visualization  “A  picture  is  worth  a  thousand  words.”  This  old  adage  is 
still  true  today,  especially  when  dealing  with  complex  and  abstract  concepts.  The  visual 
system  provides  the  application  specialist  with  a  graphical  view  of  the  structured  object 
base,  as  well  as  the  application  software  architecture  generated  to  satisfy  his  requirements. 
By  reviewing  these  “pictures,”  the  application  specialist  can  more  fully  understand  the 
components  available  for  composition  and  the  application  just  composed.  Moreover,  the 
visual  system  will  also  be  capable  of  inserting  new  instances  of  domain  objects  into  the 
structured  object  base,  editing  domain  objects  already  in  the  object  base,  and  executing 
the  application  composer.  It  also  provides  the  capability  to  extend  the  technology  base, 
enabling  the  application  specialist  and/or  the  software  engineer  to  add/modify  domain 
object  classes,  add/modify  generic  components,  and  add/modify  architectural  fragments. 

The  visual  system  is  addressed  in  more  detail  in  (44). 

3.4  Related  Research 

Several  other  research  efforts  have  addressed  various  aspects  of  the  system  we  are 
attempting  to  develop.  This  section  summarizes  this  related  work  and  analyzes  the  simi¬ 
larities  to  and  differences  from  our  project. 

3.4‘1  Hierarchical  Software  Systems  With  Reusable  Components  Don  Batory  and 
Sean  O’Malley  are  working  to  incorporate  an  engineering  culture  into  software  engineering. 
The  traditional  engineering  mindset  dictates  that  new  systems  are  created  by  fitting  well- 
tested,  well-defined,  and  readily  available  building  blocks  into  a  well-understood  blueprint 
or  architecture,  which,  if  properly  used,  is  guaranteed  to  produce  the  desired  system.  To 
this  end,  they  have  developed  a  “domain-independent  model  of  hierarchical  software  design 
and  construction  that  is  based  on  interchangeable  software  components  and  large-scale 
reuse”  (5:2). 

In  Batory  and  O’Malley’s  view,  each  interchangeable  component  consists  of  an  in¬ 
terface  (everything  externally  visible)  and  an  implementation  (everything  else).  Different 
components  with  the  same  interface  belong  to  a  realm.  All  the  components  in  a  realm  are 
considered  to  be  interchangeable  or  “plug-compatible”  (5:3)  because  they  have  identical 
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interfaces.  Symmetric  components  have  at  least  one  parameter  from  their  own  realm  and 
can  be  combined  in  “virtually  arbitrary  ways”  (5:2)  (also  see  Figure  3.4).  Conceptually, 
components  are  seen  as  layers  or  building  blocks  for  an  application;  a  system  is  seen  as  a 
stacking  of  components,  i.e.,  a  composition  of  components.  Constraints  on  stacking  com¬ 
ponents  (i.e.,  rules  of  composition)  are  derived  from  the  compatibility  of  their  interfaces. 

Hierarchical  software  system  design  recognizes  that  constructing  large  software  sys¬ 
tems  is  a  matter  of  addressing  only  two  issues:  which  components  should  be  used  in  a 
construction  and  how  those  components  are  to  be  combined  together  (5:16).  It  employs 
an  open  software  architecture,  which  is  limited  only  by  the  inherent  ability  of  the  compo¬ 
nents  to  be  combined,  i.e.,  by  their  interfaces.  Symmetric  components  have  no  inherent 
composition  restrictions;  thus,  composition  rules  are  simplified  while  ensuring  maximum 
design  flexibility  and  potential  reusability  of  components. 


Given  the  following  plug-compatible  components: 

A[x:R],  B[x:R],  C[x:R] 

Some  of  the  valid  compositions  include: 


A[B[C1]  B[A[C]]  C[A[B]]  C[B[A]] 


Figure  3.4.  Combining  Plug-Compatible  Components 
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Concept 

Grammar 

Parameterized  Components 

Productions  with  non-terminals  on  right 

Parameterless  Components 

Productions  that  only  reference  terminals 

Symmetric  Components 

Recursive  production 

Component  Interface 

Left  side  of  a  production 

Implementation 

Right  side  of  a  production 

Realm 

Set  of  all  productions  with  the  same  head 

Software  System 

Sentence 

Rules  of  Composition 

Semantic  error  checking 

Table  3.1.  Analogy  to  Grammar 


Batory  and  O’Malley  use  an  interesting  analogy,  equating  their  concepts  to  a  gram¬ 
mar,  as  shown  in  Table  3.1  (5:5).  Using  this  analogy,  a  domain  is  a  language.  Consider 
the  following  example  (5:5): 

S  =  {a,  b,  c}  5  -  a  I  6  I  c 

R  =  {  g[x:S],  h[x:S],  i[y:R]}  R^gS\hS\iR 


A  realm  S,  having  a  set  of  components  (a,  b,  and  c),  corresponds  to  a  production  where 
the  non-terminal  S  can  be  replaced  by  either  a,  b,  or  c.  Whenever  a  component  from  realm 
S  is  needed,  a,  b,  or  c  could  be  used,  depending  on  the  behavior  and  level  of  detail  needed. 
A  realm  R,  whose  components  g,  h,  and  i  require  parameters  from  realms  S,  S,  and  R, 
respectively,  can  be  represented  by  a  production  where  a  non-terminal  can  be  replaced  by 
both  a  terminal  and  a  non-terminal.  The  non-terminals  on  the  right-hand  side  are  the 
realms  from  which  the  parameters  are  provided.  The  complete  analogy  is  summarized  in 
Table  3.1. 

Batory  and  O’Malley’s  work  provides  support  for  our  research.  It  confirms  the  un¬ 
derlying  principle  of  an  application  generator:  building  software  systems  from  reusable 
components  is  “simply”  a  matter  of  selecting  which  components  to  use  and  deciding  how 
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to  compose  them  together.  It  reinforces  our  intention  to  use  an  object-oriented  approach 
in  designing  our  system.  It  also  illustrates  the  role  of  component  interfaces  in  system  com¬ 
position  and  demonstrates  the  importance  of  consistent  interfaces  and  composition  styles 
in  developing  rules  for  combining  components. 

On  the  other  hand,  the  Batory /O’Malley  work  falls  short,  in  some  ways,  of  what  we 
are  attempting.  It  does  not  incorporate  a  mechanism  for  an  application  specialist  to  specify 
new  applications  in  domain-specific  terms;  this  is  a  primary  emphasis  of  our  project.  It  also 
does  not  seem  to  provide  for  tailoring  of  component  composition  to  suit  the  application 
being  built;  composing  component  A  with  component  B  into  component  C  will  always 
produce  the  same  behavior  for  C.  We  want  to  be  more  flexible  in  our  compositions  and 
allow  A  and  B  to  be  composed  into  C  in  one  situation  and  C  in  a  different  situation, 
depending  on  how  the  application  specialist  specifies  the  composition. 

3.4-2  Automatic  Programming  Technologies  for  Avionics  Software  The  Lockheed 
Software  Technology  Center  has  developed  the  Automatic  Programming  Technologies  for 
Avionics  Software  (APTAS)  system  pictured  in  Figure  3.5  (25:2).  The  APTAS  system, 
built  for  the  target  tracking  domain,  ’’takes  a  tracking  system  specification  input  via  user 
interface  with  dynamic  forms  and  a  graphical  editor,  and  synthesizes  an  executable  tracker 
design”  (25:1).  An  application  specialist  defines  a  new  tracking  application  by  answering 
questions  which  appear  in  pop-up,  menu-like  forms.  His  answers  determine  which  addi¬ 
tional  questions  are  to  be  asked  as  he  is  guided  through  specifying  a  new  tracker.  When  all 
pertinent  specifications  have  been  entered  (defaults  exist  for  questions  which  are  left  unan¬ 
swered),  the  application  specialist  generates  a  software  architecture  for  the  new  tracker 
via  the  architecture  generator.  A  graphical  user  interface  provides  a  “picture”  of  the  ap¬ 
plication  architecture  and  allows  the  user  to  change  it  interactively.  After  the  application 
specialist  is  satisfied  with  the  architecture  just  created,  he  generates  executable  code  to 
implement  that  architecture  via  the  synthesis  engine  (25).  He  can  also  invoke  a  run-time 
display  which  facilitates  testing  and  analyzing  the  tracker  just  created. 

The  Tracking  Taxonomy  and  Coding  Design  Knowledge  Base  is  at  the  center  of  the 
APTAS  system.  It  contains  the  system’s  specification  forms,  the  primitive  modules  from 
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which  new  trackers  are  constructed,  and  the  composition  rules  which  establish  how  prim¬ 
itive  modules  are  to  be  combined.  The  application  specialist’s  answers  to  the  questions 
on  the  specification  forms  progressively  reduce  the  number  of  primitive  modules  which 
are  candidates  for  incorporation  into  the  new  tracker.  The  architecture  generated  upon 
completion  of  the  forms  specification  is  synthesized  into  an  executable  intermediate  lan¬ 
guage,  Common  Intermediate  Design  Language  (CIDL).  The  CIDL  code  can  be  executed 
to  demonstrate  system  behavior.  If  the  system  behaves  as  desired,  the  CIDL  representa¬ 
tion  can  then  be  transformed  into  Ada  code.  The  use  of  an  intermediate  representation, 
such  as  CIDL,  localizes  the  code  translation  function  and  enables  languages  other  than 
Ada  to  be  targeted  more  easily. 

The  APTAS  primitive  modules  and  their  composition  rules  are  also  written  in  CIDL. 
Extending  the  system  involves  writing  new  primitive  modules  and  incorporating  references 
to  these  new  modules  into  the  appropriate  composition  rules  and  specification  forms.  This 
is  generally  considered  to  be  a  software  engineer’s  task  (rather  than  an  application  spe¬ 
cialist’s),  as  CIDL  is  a  software  specification  language  and  few  tools  exist  to  simplify  the 
process. 

APTAS  is  strikingly  similar  to  the  system  we  envision.  It  clearly  demonstrates  that 
the  concept  of  user-initiated  composition  and  generation  of  domain-specific  systems  is 
feasible.  It  allows  application  specialists  to  specify  new  applications  in  domain-specific 
terms,  by  way  of  menu-like  specification  forms.  It  also  provides  a  sophisticated  graphical 
user  interface  which  can  be  used  to  construct  and/or  edit  the  tracker  system,  as  well  as  to 
view  the  structure  of  the  architecture. 

There  are,  however,  some  major  differences  between  APTAS  and  the  system  we 
are  developing.  APTAS’s  use  of  a  domain-specific  language  is  implicit  and  embodied  in 
its  graphical  user  interface.  Our  domain-specific  language,  on  the  other  hand,  is  explicit 
and  its  grammar  is  usable  in  both  textual  and  graphical  modes.  We  believe  this  provides 
advantages  to  both  the  software  engineer  and  application  specialist  in  terms  of  adaptability, 
flexibility,  and  ease  of  use.  In  addition,  APTAS  currently  lacks  a  set  of  convenient  tools  to 
facilitate  extending  its  knowledge  base;  such  a  toolset  is  an  integral  part  of  our  system. 
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3.4-3  Model-Based  Software  Development  The  Software  Engineering  Institute’s  (SEI) 
Software  Architectures  Engineering  (SAE)  Project  has  proposed  a  concept  called  Model- 
Based  Software  Development  (MBSD)  (24).  Like  Batory  and  O’Malley,  MBSD  strives  to 
apply  traditional  engineering  principles  to  software  development  by  exploiting  prior  ex¬ 
perience  to  solve  similar  problems.  This  prior  experience  is  codified  in  models,  “scalable 
units  of  reusable  engineering  experience”  (24:11),  which  are  stored  in  a  technology  base. 
In  a  mature  engineering  domain,  the  technology  base  will  contain  “all  the  components  an 
engineer  needs  to  predictably  solve  a  class  of  problems,  and  the  tools  and  methods  needed 
to  predictably  fabricate  a  product  from  the  components  specified  by  the  engineer”  (24:4). 
Under  MBSD,  software  development  follows  the  engineering  paradigm:  reuse  existing,  ma¬ 
ture  models  rather  than  starting  from  scratch  for  each  new  development.  This  involves 
much  more  than  code  reuse;  the  requirements  analysis,  design,  and  software  architecture 
are  reused  each  time  the  corresponding  model  is  used. 

MBSD  uses  a  technology  base,  a  repository  of  models  and  composition  rules  that 
share  common  engineering  goals.  Each  model  is  mapped  to  a  specification  form  and  a 
software  template  for  the  target  application  language.  The  specification  form  is  a  text- 
based  description  which  uniquely  identifies  a  specific  instance  of  a  model.  The  software 
template  is  code  containing  place  holders,  which  are  replaced  with  information  from  the 
specification  form  (24:10). 

As  part  of  MBSD,  the  SEI  uses  the  Object-Connection-Update  (OCU)  model  as 
a  consistent  pattern  of  design,  a  software  architecture.  This  model  is  especially  suited 
to  domains  where  the  real  world  can  be  modeled  as  a  collection  of  related  systems  and 
subsystems  (24:17).  Partitioning  a  system  into  subsystems  provides  different  levels  of 
abstraction,  giving  the  flexibility  to  replace  a  subsystem  with  another  that  either  provides 
a  different  function  or  has  a  different  level  of  detail.  In  the  OCU  model,  subsystems  consist 
of  a  controller,  a  set  of  objects,  an  import  area,  and  an  export  area  as  pictured  in  Figure  3.6 
(24:18). 
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Objects 


Figure  3.6.  OCU  Subsystem  Construction 


1.  Controller  -  Performs  the  mission  of  the  subsystem  by  requesting  operations  from  the 
objects  it  connects.  A  controller  is  passive,  triggered  by  a  call  to  perform  its  mission, 
and  depends  on  the  other  subsystem  components  to  accomplish  that  mission. 

2.  Objects  -  Model  behavior  of  real-world  entities  and  maintain  individual  state  infor¬ 
mation.  An  object  is  passive,  triggered  by  a  call  from  the  controller  to  which  it  is 
connected. 

3.  Import  Area  -  Makes  data  external  to  the  subsystem  available  to  the  controller  and 
its  objects. 

4.  Export  Area  -  Makes  data  internal  to  the  subsystem  available  to  the  other  subsys¬ 
tems. 


Both  controllers  and  objects  have  standard  procedural  interfaces  used  by  external 
controllers  or  application  executives  to  invoke  some  action.  Controllers  have  the  following 
procedures  (24:19): 


1.  Update  -  Updates  the  OCU  network  based  on  state  data  in  the  import  area  and 
furnishes  new  state  data  to  the  export  area. 

2.  Stabilize  -  Puts  the  system  in  a  state  consistent  with  the  current  scenario. 

3.  Initialize  -  Loads  the  configuration,  creates  objects,  and  defines  the  OCU  network. 
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4.  Configure  -  Establishes  the  physical  connection  between  import  area  and  input  data 

as  well  as  export  area  and  the  output  data. 

5.  Destroy  -  Deallocates  the  subsystem. 

All  objects  have  procedures  analogous  to  those  for  controllers,  but  operating  on  a  single 
object  instance.  Specifically,  these  procedures  are  (24:20); 

1.  Update  -  Calculates  the  new  state  based  on  input  data  and  the  current  state. 

2.  Create  -  Creates  a  new  instance  of  the  object. 

3.  SetFunction  -  Changes  or  redefines  the  function  used  to  calculate  the  state. 

4.  SetState  -  Directly  changes  the  object’s  state. 

5.  Destroy  -  Deallocates  the  object. 

These  well-defined  and  consistent  interfaces  for  controllers  and  objects  facilitate  and  sim¬ 
plify  the  application  composition  process. 

MBSD  provides  some  significant  insights  upon  which  to  base  our  research  effort.  Its 
focus  on  the  reuse  of  validated,  engineering  experience  is  attractive  and  we  have  adopted 
the  notion  of  storing  such  information  in  a  technology  base.  The  OCU  model  provides  a 
realistic  approach  toward  composing  primitive  objects  into  application-specific  subsystems. 

3.4-4  Extensible  Domain  Models  The  Kestrel  Interactive  Development  System 
(KIDS)  is  a  knowledge- based  system  that  allows  for  the  capture  and  development  of  do¬ 
main  knowledge  (39).  The  representation  of  the  domain  knowledge  constitutes  a  domain 
model,  and  these  domain  models  are  called  domain  theories.  Essentially,  the  domain  the¬ 
ory  provides  a  formal  language,  natural  to  specialists  in  that  domain,  for  specifying  the 
problem  they  want  to  solve.  The  KIDS  system  provides  support  for  constructing,  extend¬ 
ing,  and  composing  domain  theories,  and  over  90  theories  have  been  built  up  in  the  system 
(39).  Additionally,  the  set  of  domain  theories  developed  during  the  domain  modeling  effort 
serves  as  the  basis  for  software  synthesis. 

The  foundations  of  the  KIDS  approach  emerged  from  years  of  research  into  the 
specification  and  synthesis  of  programs  (39).  Concepts  from  algebra  and  mathematical 

*Thi8  section  was  provided  by  Major  Paul  D.  Bailor 
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logic  are  used  to  model  application  domains  and  synthesize  verifiably  correct  software. 
Domain  modeling  entails  the  analysis  of  the  domain  into  the  basic  types  of  objects,  the 
operations,  on  them,  and  their  properties  and  relationships.  The  domain  model  is  then 
expressed  as  a  domain  theory.  Theories  are  useful  for  modeling  application  domains  for 
the  following  reasons. 


1.  The  basic  concepts,  objects,  activities,  properties,  and  relationships  of  the  domain 
are  captured  by  the  types,  operations,  and  axioms  of  a  theory. 

2.  Any  queries,  responses,  situation  descriptions,  hypothetical  scenarios,  etc.  are  ex¬ 
pressed  in  the  language  defined  by  the  domain  theory. 

3.  The  semantics  of  the  application  domain  are  captured  by  the  axioms,  inference  rules, 
and  specialized  inference  procedures  associated  with  the  domain  theory. 

4.  Simulation,  query  answering,  analysis,  verification  of  properties,  and  synthesis  of 
code  are  supported  by  inference  within  the  domain  theory. 

5.  Various  operations  on  models  such  as  abstraction,  composition,  and  interconnection 
are  supported  by  well-known  theory  operations  of  parameterization,  importation, 
interpretation  between  theories,  and  others.  Thus,  a  high  degree  of  extensibility  is 
obtained. 

3.5  Specific  System  Concept 

Several  aspects  of  the  system  described  in  Section  3.3  depend  heavily  on  the  choice 
of  the  models  and  tools  used  in  the  implementation.  These  selections  may  impact  other 
parts  of  the  system.  Figure  3.7  is  a  modification  of  the  system  overview,  incorporating  the 
specific  models  and  tools  to  be  used.  It  represents  Architect,  the  specific  system  which  is 
to  be  implemented  during  this  research  effort. 

3.5.1  System  Overview  Figure  3.7  illustrates  how  specific  tools  and  models  further 
define  Architect.  REFINE,  as  the  domain  modeling  language,  imposes  its  structure  on  the 
domain  model  (which  will  be  represented  in  REFINE  also).  Input,  written  in  the  domain- 
specific  and  architecture  grammars,  is  processed  through  a  parser  generated  by  DIALECT. 
DIALECT  requires  two  inputs  to  generate  a  parser:  a  DIALECT  domain  model  (a  subset 
of  the  system  domain  model)  and  a  grammar  definition.  The  DIALECT  parser  creates 
abstract  syntax  trees  in  the  structured  object  base.  The  visualizer  will  be  implemented 
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Figure  3.7.  Overview  of  Specific  System 
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using  INTERVISTA.  The  SETs  OCU  nmodel  will  serve  as  our  software  architecture  model, 
providing  a  structure  around  which  to  generate  our  applications.  KIDS  will  serve  as  a 
mechanism  for  realizing  extensibility  of  the  domain  model  and  technology  base. 


3.5.2  Software  Refinery  Software  Refinery  is  a  formal-based  specification  and  pro¬ 
gramming  environment  developed  by  Kestrel  Institute  and  available  commercially  from 
Reasoning  Systems,  Inc.  We  have  selected  this  environment  in  which  to  implement  Ar¬ 
chitect  for  several  reasons,  but  the  main  factor  in  our  decision  is  REFINE’s  powerful, 
integrated  toolsets  that  allow  rapid  prototyping.  This  decision  has  many  implications  on 
how  the  system  wiU  operate,  as  we  will  show. 

3. 5. 2. 1  Capabilities  The  REFINE  environment  consists  of  the  following  tools: 


1.  A  programming  language  (REFINE)  which  includes  set  theory,  logic,  transformation 
rules,  pattern  matching,  and  procedures  (35:1-2).  The  REFINE  language  provides 
a  wide  range  of  constructs  from  very  high  level  to  low  level,  making  it  suitable  for 
various  programming  styles,  including  use  as  an  executable  specification  language. 

2.  An  object  base  which  can  be  queried  and  modified  through  REFINE  programs  (35:1- 
2).  “Object  classes,  types,  functions  and  grammars  are  among  the  objects  you  can 
define  and  manipulate”  (35:1-4)  with  several  built-in  and  powerful  object  base  ma¬ 
nipulation  tools. 

3.  A  language  definition  facility  (DIALECT)  which  allows  design  of  languages  using  an 
extended  Backus  Naur  Form  notation.  REFINE  supplies  a  lexical  analyzer,  parser, 
pattern  matcher,  pattern  constructor,  and  prettyprinter  for  the  language  (35:1-2). 

4.  A  toolset  (INTERVISTA)  which  is  useful  in  creating  a  visual,  window-based  inter¬ 
active  user  interface. 

3. 5. 2. 2  Domain  Modeling  Language  Some  domain  modeling  languages  al¬ 
ready  exist  for  expressing  domain  knowledge  within  a  formalized  domain  model;  we  con¬ 
sidered  two  such  languages:  the  Requirements  Modeling  Language  (RML)  and  REFINE. 

RML  was  designed  as  a  research  tool  as  part  of  the  Tajcis  Project  at  the  University  of 
Toronto.  It  allows  “direct  and  natural  modeling  of  the  world”  (16:3)  in  an  object-oriented 
manner  which  “captures  and  formalizes  information  that  is  left  informal  or  not  documented 
in  current  approaches”  (16:1).  RML  can  express  “assertions  (what  should  be  true  in  the 
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world),  as  well  as  entities  (the  ‘things’  in  the  world)  and  actions  (happenings  that  cause 
change  in  the  world)”  (16:4).  This  is  precisely  the  type  of  information  we  want  to  capture 
in  our  domain  model. 

Even  though  both  RML  and  REFINE  appear  to  be  capable  of  expressing  the  kind  of 
information  we  require  in  the  domain  model,  we  chose  REFINE  as  our  domain  modeling 
language  for  the  following  reasons: 


1.  REFINE  provides  an  integrated  environment  including  programming  constructs  and 
powerful  object  base  manipulation  tools.  Use  of  REFINE’s  existing  tools  eliminated 
the  need  to  write  our  own,  allowing  more  time  to  be  spent  on  the  research  itself. 

2.  RML  is  not  an  executable  language;  no  compilers  currently  exist.  To  use  RML,  we 
would  be  forced  to  develop  a  compiler,  a  considerable  overhead  to  our  project.  As 
REFINE  is  also  capable  of  expressing  the  information  we  require,  it  is  unclear  what 
added  benefits  RML  could  provide  to  justify  this  additional  expense. 

3.  The  REFINE  environment  includes  compatible  tools  (DIALECT  and  INTERVISTA) 
useful  in  other  portions  of  the  system. 

4.  REFINE  is  a  commercially  available  and  supported  product. 

5.  Members  of  the  research  team  already  possessed  a  working  knowledge  of  REFINE. 

3. 5.2.3  Parser  “DIALECT  is  a  tool  for  manipulating  formal  languages”  (34:1- 
1).  A  part  of  the  REFINE  software  development  environment,  DIALECT  generates  appro¬ 
priate  lexical  analyzers,  parsers  and  pretty-printers  for  user-specified,  context-free  gram¬ 
mars.  Valid  input  is  parsed  and  stored  as  abstract  syntax  trees  in  the  REFINE  object 
base,  according  to  the  structure  established  in  the  DIALECT  domain  model.  The  DI¬ 
ALECT  domain  model  defines  object  classes,  object  attributes,  and  the  structure  of  the 
instances  in  the  object  base.  DIALECT  also  supports  grammar  inheritance,  allowing  for  a 
base  language  with  several  variations  or  “dialects.”  In  Architect,  the  architecture  grammar 
acts  as  the  common  base,  and  the  domain-specific  grammar  specifies  a  particular  varia¬ 
tion.  DIALECT  does  impose  restrictions  on  the  grammars.  Since  DIALECT  generates  an 
LALR(l)  parser,  the  grammar  must  be  consistent  with  this  type  of  parser.  Also,  the  pro¬ 
ductions  in  the  grammar  must  correspond  to  the  structure  defined  in  the  domain  model. 
Altering  some  productions  may  require  updating  the  DIALECT  domain  model. 
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3. 5. 2.4  Structured  Object  Base  The  structured  object  base  was  implemented 
using  the  REFINE  object  base.  REFINE  includes  many  tools  which,  when  combined  with 
REFINE  code,  provide  all  of  the  functions  necessary  to  manipulate  the  structured  object 
base.  However,  the  object  base  must  be  accessed  through  the  REFINE  environment. 

3. 5. 2. 5  Technology  Base  Models  in  the  technology  base  were  represented  as 
REFINE  code  and  stored  in  REFINE’s  object  base.  Although  separate  conceptually,  the 
technology  base  and  structured  object  base  are  not  physically  separate.  Access  is  controlled 
by  Architect  to  avoid  any  confusion. 

3. 5.2.6  Visual  System  INTERVISTA  provides  a  tool  set  with  which  to  gen¬ 
erate  a  window-based  graphical  user  interface.  It  is  compatible  with  the  other  REFINE 
tools;  therefore,  it  is  easily  integrated.  INTERVISTA  can  access  the  REFINE  object  base, 
so  all  its  required  data  is  readily  available. 

3.5.3  Object-Connection- Update  Model  We  have  selected  the  Software  Engineering 
Institute’s  Object- Connection- Update  (OCU)  model  for  our  software  architecture  model. 
As  such,  it  provides  a  framework  for  composing  applications  -  a  standardized  pattern  of 
design  for  all  applications  and  their  components.  The  OCU  model’s  consistent  interfaces 
enable  all  components  to  be  accessed  in  the  same  manner  and  its  intercomponent  commu¬ 
nication  scheme  ensures  that  each  component  can  readily  access  the  external  data  needed 
for  its  processing.  Currently,  our  focus  is  on  implementing  the  subsystem  aspect  of  the 
OCU  model;  the  hardware  interface  portion  of  the  model  will  be  addressed  in  follow-on 
research  efforts. 

The  choice  of  the  OCU  model  for  our  software  architecture  model  had  certain  impli¬ 
cations  for  Architect. 

1.  Terminology  -  In  keeping  with  the  OCU  model,  we  will  refer  to  domain  primitive 
objects  as  “objects,”  compositions  of  objects  as  “subsystems,”  the  locus  of  control  of 
a  subsystem  as  a  “controller,”  and  the  overall  application  itself  as  an  “executive”  (see 
Sections  4.2. 1.3  and  4.2.2. 1  for  a  more  detailed  discussion  of  the  executive).  External 
data  needed  by  an  object  are  “input-data,”  whereas  data  to  be  made  externally 
available  are  “output-data.”  An  “import  area”  serves  as  a  focal  point  for  all  external 
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data  needed  by  the  subsystem  and  an  “export  area”  is  the  focal  point  for  all  internal 
data  to  be  made  available  to  other  subsystems.  The  OCU  model’s  names  for  the 
object  and  controller  procedural  interfaces  have  also  been  retained. 

2.  Use  of  a  Technology  Base  -  Although  the  concept  of  storing  reusable  domain  knowl¬ 
edge  or  models  in  a  technology  base  is  not  unique  to  the  OCU  model,  it  is  a  funda¬ 
mental  component  of  Model- Based  Software  Development  of  which  the  OCU  model 
is  a  part. 

3.  Domain  Analysis  -  The  OCU  model  deals  with  objects  and  subsystems.  This  imposes 
a  constraint  on  the  domain  engineer  and  will  impact  the  manner  in  which  domain 
analysis  is  conducted.  Under  the  OCU  model,  the  domain  engineer  must  model  the 
domain  in  terms  of  subsystems  which  can  be  composed  from  lower-level,  more  prim¬ 
itive  objects.  Many  domains  can  be  naturally  modeled  in  such  a  way;  with  other 
domains,  a  new  mindset  may  be  needed  to  incorporate  the  subsystem/object  require¬ 
ments  of  the  OCU  model.  Alternatively,  an  additional  class  of  software  architectures 
may  need  to  be  defined. 

4.  Definition  of  Domain  Objects  -  The  OCU  model  requires  that  all  objects  be  defined 
in  the  same  manner.  Each  object  has  state  data,  other  descriptive  information, 
input-data/output-data  definitions,  and  the  following  procedural  interfaces:  Update, 
Create,  SetFunction,  SetState,  and  Destroy.  These  requirements  dictate  how  the 
objects  will  be  constructed,  severely  limiting  implementation  choices.  However,  it  is 
this  very  limitation  which  provides  the  flexibility  that  allows  the  domain  objects  to 
be  successfully  composed  to  satisfy  the  application  specialist’s  specification. 

5.  Definition  of  Architectural  Fragments  -  The  OCU  model  requires  that  all  architec¬ 
tural  fragments  (subsystems)  be  described  in  the  same  way.  All  subsystems  have 
an  import  area,  export  area,  controller,  and  objects.  Each  controller  has  the  foUow- 
ing  procedural  interfaces:  Update,  Stabilize,  Initialize,  Configure,  and  Destroy.  As 
with  the  objects,  this  apparent  limitation  on  implementation  choices  actually  pro¬ 
vides  great  flexibility  in  composing  subsystems  and  combining  them  into  a  complete 
application. 

6.  Composition  Rules  -  The  standardized  object/subsystem  definitions  and  interfaces  of 
the  OCU  model  simplify  application  composition.  There  are  no  inherent  restrictions 
preventing  one  component  from  being  combined  with  another;  all  composition  rules 
are  domain-specific  and  do  not  derive  from  the  software  architecture. 

7.  Intercomponent  Communication  -  The  OCU  model  establishes  and  enforces  a  stan¬ 
dard  method  for  intercomponent  communication.  Communication  external  to  the 
subsystem  is  localized  in  the  import  area  which  obtains  the  necessary  input-data 
for  all  objects  within  the  subsystem.  This  localization  of  communication  concerns 
within  the  narrow  guidelines  imposed  by  this  scheme  simplifies  intermodule  commu¬ 
nication:  subsystems  can  readily  obtain  needed  external  information  in  a  consistent 
manner  and  changes  in  the  low-level  implementation  of  the  communication  process 
are  hidden  from  the  subsystems/objects. 

8.  Structure  of  the  Resulting  Application  Specification  -  Obviously,  the  specification 
produced  by  the  application  composer  is  impacted  by  the  choice  of  a  software  ar- 
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chitecture  model.  The  OCU  model  produces  an  application  (an  “executive”)  which 
is  composed  of  subsystems.  These  subsystems  can  be  decomposed  into  objects  and 
lower-level  subsystems,  if  appropriate.  This  hierarchical  structure  is  preserved  in  the 
generated  specification. 

The  OCU  model  is  the  result  of  years  of  research  and  experimentation  by  the  SEI. 
It  has  been  used  successfully  in  the  flight  simulator,  missile,  and  engineering  simulator 
domains  (10)  and  appears  to  provide  a  suitable  structure  for  composing  applications  within 
our  application  composition  system. 

3.6  Conclusion 

Software  engineering  may  be  on  the  brink  of  a  new  era,  an  era  in  which  software 
engineers  develop  knowledge  about  generating  software  systems  and  application  specialists 
actually  create  the  software  systems  using  familiar,  domain-oriented  terms.  Our  research, 
which  builds  on  important  work  already  accomplished  by  various  researchers,  is  designed 
to  demonstrate  the  feasibility  of  such  an  application  composer. 
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IV.  Software  System  Design  Overview 


This  chapter  presents  an  overview  of  the  high-level  design  of  the  application  com¬ 
position  system  introduced  in  Chapter  III  (Architect).  It  discusses  various  preliminary 
design  decisions  (which  stem  from  the  choice  of  the  OCU  model  for  the  software  architec¬ 
ture  of  the  composed  applications)  by  reviewing  the  OCU  model  and  identifying  certain 
adaptations  which  were  made  for  this  implementation.  In  addition,  the  implementation’s 
goals/objectives,  conventions,  and  data  structures  are  examined. 

4- 1  High-Level  System  Design 

This  section^  describes  the  high-level  design  of  Architect,  the  system  presented  in 
Section  3.5. 

4.1.1  Design  Goals  Throughout  the  design  process,  an  attempt  was  made  to  opti¬ 
mize  several  fundamental  goals.  These  goals  include: 

4. 1.1.1  Domain  Independence  Since  Architect  must  be  applicable  to  any  do¬ 
main,  it  should  not  directly  incorporate  (i.e.,  “hardcode” )  knowledge  about  a  specific 
domain  or  type  of  domain;  the  technology  base  is  the  proper,  sole  repository  for  such 
domain-specific  information.  If  any  domain  knowledge  were  to  be  included  in  Architect, 
code  changes  would  likely  be  required  before  it  could  be  used  with  a  new  or  modified 
domain.  Obviously,  this  greatly  limits  the  applicability  and  usability  of  the  system. 

4. 1.1. 2  Extensibility  It  would  be  very  naive  to  assume  that  an  initial  domain 
analysis  will  reveal  all  possible  knowledge  about  a  particular  domain  and  that  the  domain 
model,  which  formalizes  this  knowledge,  will  never  change.  In  reality,  the  domain  model 
will  continue  to  evolve  as  existing  knowledge  is  further  refined  and/or  new  domain  infor¬ 
mation  is  added  to  the  system.  If  this  evolution  cannot  be  achieved  easily.  Architect  will 
quickly  become  obsolete. 

'This  section  was  jointly  written  by  Captains  Cynthia  Anderson  and  Mary  Anne  Randour.  It  is  included 
in  AFIT  Technical  Report  AFIT/EN/TR-92-5  and  also  appears  in  (33) 
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4-1-1-3  Flexibility  Because  the  concept  of  application  composers  is  rather 
new,  we  do  not  yet  know  how  application  specialists  and  software  engineer  s  best  be 
able  to  use  them.  Architect,  therefore,  must  be  flexible  enough  to  allow  multiple  methods 
for  performing  various  tasks  and  a  wide  range  of  application  specification  options. 

4- 1.1 -4  Usability  Application  specialists,  the  primary  users  of  this  system, 
must  have  some  degree  of  software  programming  knowledge,  but  they  can  not  be  expected 
to  have  the  same  degree  of  understanding  as  a  software  engineer.  Therefore,  it  is  important 
that  the  system  not  require  detailed  programming  knowledge  from  its  users.  In  many  cases, 
the  goals  of  usability  and  flexibility  conflicted,  so  a  balance  had  to  be  found. 


Edit  ObiMt  Bu« 

Figure  4.1.  System  Operations 


4.1.2  Concept  of  Operations  The  steps  which  are  followed  when  using  this  appli¬ 
cation  generator  are  depicted  in  Figure  4.1  as  labels  on  the  flow  arrows.  The  application 
specialist  must  first  identify  all  objects  to  be  used  in  the  application  specification  and 
enter  (parse)  them  into  the  structured  object  base  using  domain-specific  and  architecture 


grammars.  Some  of  these  objects  may  require  further  information  before  they  are  fully  de¬ 
fined  (e.g.,  previously  saved  objects  must  be  located  and  loaded,  “holes”  in  generic  object 
templates  must  be  filled,  etc.);  the  application  specialist  provides  this  additional  informa¬ 
tion  by  completing  the  application  definition.  Although  the  application  definition  may  be 
considered  complete  from  the  user’s  point  of  view,  some  data  needed  by  the  system  may 
not  yet  be  directly  available;  preprocessing  the  application  specification  automatically  gen¬ 
erates  this  essential  information.  When  the  application  is  fully  defined,  semantic  checks 
axe  performed  to  identify  any  composition  errors,  which  must  be  corrected  before  the  ap¬ 
plication’s  behavior  can  be  simulated.  At  any  time,  the  application  specification  can  be 
changed  (edited),  usually  in  response  to  a  semantic  error  or  to  include  additional  data.  If 
no  semantic  errors  exist  and  no  additions/changes  have  been  made,  the  application’s  be¬ 
havior  can  be  simulated  (executed).  If  the  application  behaves  as  the  application  specialist 
intended,  he  may  generate  a  formal  specification  for  the  composed  application  which  will 
be  used  by  an  automatic  code  generator  to  produce  a  fully  realized  application. 


Figure  4.2.  System  Structure 


4-1.3  Software  System  Design  The  eight  steps  outlined  above  correspond  directly 
to  Architect’s  eight  top-level  modules  as  shown  in  Figure  4.2.  The  highest  level  module, 
the  visual  system,  will  eventually  control  each  of  the  other  modules  as  weU  as  all  user  in¬ 
teractions  through  a  graphical  interface.  However,  the  basic  system  was  developed  before 
the  visual  system  was  completed;  therefore,  a  simple  user  interface,  which  is  easily  re¬ 
placed,  was  implemented.  In  the  system  design,  we  have  made  a  conscious  decision  to  keep 
application  specification  a  domain-oriented,  rather  than  programming-oriented,  process. 
The  system  is  designed  to  use  all  available  domain  knowledge  to  insulate  the  application 
specialist,  as  much  as  possible,  from  programming  details,  conventions,  and  jajrgon. 

Each  of  Architect’s  major  functions  is  encapsulated  into  one  of  the  system’s  top-level 
modules.  These  modules  are  further  discussed  in  the  remainder  of  this  section. 

4-1.3. 1  Parse  Using  REFINE,  data  can  be  input  into  the  object  base  using 
one  of  two  different  methods:  through  a  grammar  or  directly  by  using  built-in  REFINE 
functions. 

Using  the  DIALECT  tool  allows  the  application  specialist  to  reuse  his  input  files 
as  templates  for  other  application  definitions.  The  grammar  also  provides  a  consistent 
format  for  saving  objects  from  the  object  base  into  the  technology  base.  The  domain- 
specific  portions  of  the  grammar  can  be  separated  from  the  architectural  components. 
DIALECT  allows  grammars  to  inherit  the  productions  of  other  grammars.  In  this  case, 
each  domain-specific  grammar  inherits  the  same  architecture  grammar.  If  the  domain  is 
changed,  only  one  grammar  is  affected.  However,  the  application  specialist  must  conform 
to  the  structure  imposed  by  the  grammars.  If  the  current  domain  changes,  the  domain- 
specific  grammar  will  require  appropriate,  corresponding  changes.  If  a  different  domain  is 
to  be  used,  a  new  domain-specific  grammar  must  be  written;  however,  grammars  for  other 
domains  can  serve  as  a  guide  to  facilitate  ci 'bating  new  grammars. 

An  alternative  approach  is  to  build  REFINE  tools  that  allow  the  application  specialist 
to  interactively  enter  the  objects  into  the  object  base.  This  method  migrates  most  easily 
to  the  visual  interface  planned  for  a  follow-on  project  (44).  Also,  this  method  is  domain- 
independent.  However,  additional  code  must  be  written  to  save  portions  of  the  object 
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base.  The  developer  must  devise  a  standard  format  for  the  files  to  allow  this  data  to  be 
read  back  into  the  object  base. 


The  best  approach  is  to  combine  the  two  methods.  The  application  specialist  can 
input  objects  into  the  object  base  either  through  a  grammar  or  interactively.  The  grammar 
provides  a  format  for  saving  and  retrieving  all  objects  in  the  object  base  and  a  means  of 
saving  “templates”  for  application  definitions.  The  interactive  portions  extend  more  readily 
to  the  visual  system. 

4- 1.3. 2  Complete  Application  Definition  After  all  of  the  application  special¬ 
ist’s  input  is  parsed  into  the  object  base,  additional  processing  is  needed  to  complete  the 
definition.  The  application  specialist  can  fully  define  an  object  in  the  grammar  or  he  can 
give  partial  information  in  one  of  three  forms:  a  generic  instance,  an  incomplete  object, 
or  an  object  to  load.  As  part  of  completing  the  application  definition,  the  system  must 
actually  instantiate  the  generic  objects,  complete  incomplete  objects  by  prompting  the  ap¬ 
plication  specialist  for  values  for  each  attribute,  and  physically  load  objects  into  the  object 
base. 


4. 1.3.3  Preprocess  Application  The  structured  object  base  now  contains  only 
“complete”,  fully-instantiated  application  components.  However,  some  critical  data  has 
not  been  specified.  For  example,  the  contents  of  a  subsystem’s  import  and  export  areas 
have  not  yet  been  identified.  These  areas  are  dependent  upon  the  inputs  and  outputs, 
respectively,  of  the  primitive  objects  which  are  controlled  by  that  subsystem.  Appropriate 
input-data  and  output-data  for  each  primitive  object  have  been  identified  during  domain 
analysis  and  are  available  to  the  system  in  the  technology  ba*'".  Using  this  knowledge, 
the  preprocessing  module  dynamically  builds  each  subsystem  1.  import  and  export  areas, 
prompting  the  application  specialist  to  indicate  where  the  import  data  will  be  obtained 
when  more  than  one  subsystem  produces  the  desired  information. 

4. 1.3.4  Perform  Semantic  Checks  Two  levels  of  semantic  checks  exist  in  Ar¬ 
chitect.  Architecture-oriented  semantic  checks  ensure  that  the  proposed  application  spec¬ 
ification  conforms  to  the  composition  requirements  of  the  OCU  model  and  that  its  behav- 
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ior  can  be  successfully  simulated  (e.g.,  all  components  exist  in  the  object  base,  applica¬ 
tion/subsystem  update  procedures  directly  reference  only  components  which  are  part  of 
the  same  application/subsystem,  data  input  to  one  subsystem  is  produced  as  output  by 
some  subsystem  in  the  application,  etc.).  Domain-specific  semantic  checks  are  knowledge- 
based,  building  on  what  is  known  about  the  domain,  its  objects,  and  previous  applications 
created  in  that  domain,  to  assist  the  application  specialist  in  composing  a  meaningful  and 
optimized  application. 

Meaningful  architecture  semantic  checks  can  be  performed  on  the  application  as  a 
whole  and  also  on  its  constituent  subsystems.  There  are  currently  no  meaningful  semantic 
checks  for  primitive  objects;  the  system  assumes  that  primitive  object  class  definitions  and 
update  procedures  have  been  correctly  constructed  by  a  software  engineer. 

4. 1.3.5  Edit  Application  If  the  application  specialist  decides  an  object  in¬ 
stance  is  not  exactly  what  was  intended,  he  can  edit  the  object.  He  can  edit  existing 
instances,  add  new  objects,  or  delete  objects.  If  the  application  specialist  modifies  the 
object  base,  he  must  also  perform  preprocessing  and  semantic  checking  on  the  entire  ob¬ 
ject  base  to  ensure  the  integrity  of  the  data  before  simulating  behavior  or  generating  the 
specification. 

The  goal  of  domain  independence  has  a  large  impact  on  how  this  module  is  designed. 
If  certain  domain  knowledge  is  embedded  in  the  source  code,  the  code  must  be  modified 
when  the  domain  changes.  If  the  code  is  completely  independent,  the  interface  may  be 
more  difficult  to  build  and  less  user-friendly  (the  system  can  not  give  detailed  prompts 
explaining  what  type  of  data  is  expected).  In  this  case,  domain  independence  is  more 
important  than  friendly  prompts. 

4. 1.3.6  Execute  Application  After  the  structured  object  base  is  fully  popu¬ 
lated  and  the  semantic  checks  have  uncovered  no  errors,  the  application’s  behavior  can 
be  simulated.  This  enables  the  application  specialist  to  ascertain  if  the  application,  as 
specified,  behaves  as  expected/desired.  Behavior  simulation  is  achieved  by  executing  the 
application’s  update  procedure,  which  consists  of  a  series  of  calls  to  subordinate  sub- 
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systems  to  execute  their  missions.  Calling  a  subsystem  to  execute  its  mission  invokes  its 
update  procedure.  Subsystem  update  procedures  consist  of  calls  to  subordinate  subsys¬ 
tems/primitive  objects,  as  well  as  if  and  while  statements  which  allow  conditional  and 
iterative  flows  of  control. 

4. 1.3.7  Save  to  Technology  Base  Since  saved  objects  can  be  retrieved  and 
parsed  back  into  the  object  base,  a  function  must  exist  to  store  objects  in  the  object  base 
into  a  file.  The  objects  must  be  stored  in  the  format  required  by  the  input  procedure,  that 
is,  the  format  must  adhere  to  the  specifications  of  the  domain-specific  and  architecture 
grammars.  Saved  application  definitions  can  later  be  retrieved  and  loaded  into  the  object 
base.  Objects  can  be  retrieved  either  through  the  grammar  or  through  the  interactive 
interface. 


4. 1.3.8  Generate  Specification  When  the  application  specialist  is  satisfied 
that  the  specified  application  behaves  as  desired,  he  can  generate  its  formal  specifica¬ 
tion.  The  formal  specification  provides  all  the  information  necessary  to  directly  code  the 
application  into  an  efficient  production  system.  Indeed,  the  formal  specification  generated 
by  this  application  composer  is  intended  to  be  input  to  an  automated  code  generation 
facility. 

4.2  Preliminary  Design  of  the  Application  Composer 

Development  of  the  full-scale  application  generator  described  in  Chapter  III  will  re- 
qture  several  years  of  research  and  experimentation.  This  thesis  effort  focuses  on  one  aspect 
of  that  project  -  the  application  composer  and,  more  specifically,  the  Preprocess,  Perform 
Semantic  Checks,  and  Execute  components.  The  implementation  of  these  components  is 
dependent  on  the  choice  of  software  architecture  for  the  composed  application.  The  Soft¬ 
ware  Engineering  Institute’s  Object  Connection  Update  (OCU)  model  was  selected  as  the 
software  architecture  for  applications  within  Architect;  the  model  can  be  easily  formalized, 
appears  to  be  applicable  to  a  variety  of  domains,  and  has  been  used  successfully  by  the  SEI 
and  other  AFIT  researchers  (7,  40)  for  developing  various  simulators.  This  section  briefly 
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reviews  the  OCU  model,  examines  some  of  the  goals/objectives  of  this  implementation  and 
describes  the  data  structures  used  to  support  it. 

4.2.1  Review  of  the  OCU  Model  The  OCU  model  describes  a  software  architecture 
that  is  especially  well-suited  for  developing  software  systems  which  can  be  “described  as 
a  set  of  subsystems”  (24:17).  It  consists  of  three  kinds  of  components:  primitive  objects, 
subsystems,  and  application  executives. 

4. 2. 1.1  Primitive  Objects  An  object  “models  the  behavior  of  a  real-world  or 
virtual  component  and  maintains  (its)  state”  (24:19).  It  is  passive,  activated  only  by  an 
outside  request  to  update  its  state.  It  is  also  very  insular,  aware  only  of  its  own  internal 
data  and  is  oblivious  to  other  objects  in  the  system  including  the  sources  of  the  external 
data  it  needs  to  update  its  own  state.  An  object’s  internal  data  include  (24:20-21): 

•  Input-Data:  Information  which  is  external  to  the  object  but  is  needed  to  update  the 
object’s  state. 

•  Output -Data:  Information  which  results  from  updating  the  object’s  state  and  which 
must  be  made  available  to  other  entities  external  to  the  object. 

•  Attributes:  Descriptive  characteristics  of  a  particular  instance  of  the  object. 

•  Current-State:  Data  which  defines  the  current  state  of  the  object. 

•  Coefficients:  Data  used  in  calculating  the  object’s  new  state;  can  be  modified  to  alter 
the  object’s  behavior  or  state  calculation. 

•  Constants:  Information  about  the  object  which  can  not  be  changed. 

Objects  can  be  activated  only  through  the  following  common,  procedural  interfaces  (24:20): 

•  Update:  Calculate  the  object’s  new  state  data  (i.e.,  encapsulates  the  object’s  behav- 
iorial  description). 

•  Create:  Allocate  a  new  instance  of  the  object. 
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•  SetFunction:  Change  the  function  used  to  calculate  the  object’s  new  state  data 
and/or  change  the  object’s  coefficients  which  can  alter  the  behavior  of  the  current 
update  function. 

•  SetState:  Change  the  object’s  state  data  directly,  bypassing  the  update  function. 

•  Destroy:  Deallocate  the  object. 

4.2. 1.2  Subsystems  A  subsystem  is  an  abstraction  which  represents  a  real- 
world  subsystem.  Some  examples  include  the  engine,  electrical  and  airframe  subsystems 
in  a  flight  simulator.  A  subsystem  consists  of  (24:18-19): 

•  A  controller:  “aggregates  a  set  of  objects  (and  possibly  lower-level  controllers)  and 
manages  the  connections  between  them”  (24:18).  It  is  “the  locus  of  a  mission  and 
the  objects  are  services  to  carry  out  the  mission”  (24:18).  Like  primitive  objects,  the 
controller  is  passive  and  insular,  aware  only  of  the  objects  it  connects  and  unaware 
of  other  subsystems  in  the  application.  A  controller  can  be  activated  only  by  one  of 
the  following  procedural  interfaces: 

-  Update:  “Update  object-connection  network  based  on  state  data  in  the  import 
area  and  provide  new  state  data  in  the  export  area”  (24:19).  That  is,  it  performs 
the  subsystem’s  mission. 

—  Stabilize:  “Converge  subsystem  consistent  with  current  scenario  and  make  ready 
to  operate...  gets  rid  of  transients”  (24:19).  In  other  words,  it  executes  the 
subsystem’s  mission  an  appropriate  number  of  times  to  let  the  data  and/or 
algorithm  converge  to  the  proper  value. 

-  Initialize:  “Activate  supporting  hardware...  create  objects  and  define  object- 
connection  network”  (24:19);  i.e.,  create  the  subsystem  and  the  subsystems/objects 
which  are  controlled  by  it. 

-  Configure:  “Program  the  transfer  characteristics  of  the  controller  and  the  ob¬ 
jects”  (24:19).  Or,  more  simply,  change  some  of  the  controlled  objects’  state 
data,  coefficients  and/or  update  functions. 
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—  Destroy:  Deallocate  the  subsystem,  as  well  as  the  subsystems/objects  which  it 
controls. 

•  An  import  ar''  i:  the  focal  point  for  external  data  needed  by  objects  within  the 
subsystem.  It  “makes  the  state  data  available  to  the  objects  by  retrieving  the  data 
from  other  subsystems’  export  areas  upon  request  for  the  data”  (24:19). 

•  An  export  area;  the  focal  point  for  data  which  is  to  be  made  available  to  external 
application  components.  “Data  is  placed  in  the  export  area  where  it  is  available  to 
other  subsystems’  import  areas”  (24:19). 

•  Objects:  the  primitive  objects  (and/or  lower-level  subsystems)  which  are  needed  to 
accomplish  the  subsystem’s  mission. 

4. 2. 1.3  Application  Executive  An  executive  is  “an  artifact  of  shared  processor 
computing  and  provides  the  operating  environment  for  the  system”  (42).  It  serves  an  a 
“activator”  for  the  subsystems  within  the  application,  directing  them  to  perform  their 
missions  as  needed.  Executives  monitor  interfaces  to  external  entities  and  “manage  time, 
the  controllers  (subsystems),  and  the  application  state  to  provide  acceptable  responses 
to  stimuli”  (42).  This  implies  that  the  executive  is  the  highest-level  component  in  an 
application  and  encapsulates  its  mission. 

4.2.2  Adapting  the  OCU  Model  for  this  Implementation  The  OCU  model  described 
above  has  proved  to  be  very  beneficial  in  separating  “reaction  strategy  (or  mission)  from 
the  providers  of  the  strategic  operations”  (42).  This  separation  is  especially  significant 
to  application  composition  systems,  as  it  allows  virtually  an  infinite  number  of  different 
missions  to  be  created  without  changing  the  system  itself.  However,  the  OCU  model  is 
currently  used  only  by  computer  professionals  as  an  off-line  tool  for  designing  and  coding 
new  software  systems;  it  is  not  used  by  end-users  to  dynamically  compose  applications 
and  simulate  their  behaviors,  as  Architect  will  allow.  The  end-product  of  the  model’s 
usage  to  date  has  been  fully-coded,  unique  software  systems  which  satisfy  a  single  (albeit 
complex)  requirement.  As  such,  various  interactions  among  elements  of  the  model  (espe¬ 
cially  import /export  areas  and  subsystems)  have  been  “hardcoded”,  based  on  the  specific 
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requirements  of  a  single  application.  An  application  composition  system  must  be  flexible, 
capable  of  supporting  a  wide  variety  of  applications  in  a  wide  range  of  domains  and  cannot 
rely  on  “hardcoded”  interactions.  Clearly,  some  additional  consideration  must  be  given  to 
an  implementation  of  the  OCU  model  which  precludes  such  “hardcoded”  interactions. 

4-2.2. 1  Application  Executive  A  fully-realized  executive,  capable  of  monitor¬ 
ing/controlling  time  and  interfaces  to  external  entities,  was  deemed  too  ambitious  for  this 
research  effort,  which  is  intended  to  demonstrate  an  application  composition  system  “proof 
of  concept;”  enhancements  to  the  application  executive  will  be  added  in  the  future.  In  this 
implementation,  an  application  consists  of  a  collection  of  subsystems  and  an  “executive 
subsystem.”  This  “executive  subsystem”  is  the  forerunner  of  a  fuUy-realized  application 
executive  and  is  treated  as  a  specialized,  high-level  subsystem  without  import  and  export 
areas.  Due  to  this  lack  of  interfaces  to  external  entities  (i.e.,  input/output  capabilities), 
there  can  be  no  external  data;  all  data  must  be  internal  to  the  application. 

4. 2.2.2  Objects  Architect  expects  that  all  to-be-combined  components  al¬ 
ready  exist;  in  fact,  creating  these  components  is  one  aspect  of  the  system’s  Parse  and 
Complete  Application  Components  phases.  Moreover,  dynamic  (that  is,  run-time)  cre¬ 
ation  and  deletion  of  objects  greatly  complicates  the  application  composition  process;  it 
is  extremely  difficult  to  develop  adequate  semantic  checks  to  ensure  that  such  a  proposed 
application  can  be  successfully  executed  under  all  conditions.  Therefore,  the  Create  and 
Destroy  OCU  object  procedural  interfaces  are  not  included  in  this  implementation  and  are 
left  for  future  research. 

4. 2. 2.3  Subsystems  As  mentioned  above.  Architect  expects  all  to-be-combined 
components  to  exist;  this  includes  subsystems  as  well  as  objects.  For  reasons  similar  to 
those  described  above,  the  Initialize  and  Destroy  OCU  subsystem  procedural  interfaces  are 
not  implemented.  In  addition,  due  to  some  uncertainty  about  their  utility,  the  Configure 
and  Stabilize  subsystem  interfaces  also  are  omitted  from  this  implementation. 

4. 2.2. 4  Import  and  Export  Areas  A  subsystem’s  import  area  is  the  focus  of 
external  data  needed  by  all  objects  aggregated  by  the  subsystem  and,  conversely,  the  export 
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area  is  the  focus  of  external  data  produced  by  those  objects.  Clearly,  with  dynamic  com¬ 
position,  the  application  composition  system  must  “know”  what  external  data  is  needed 
by /produced  by  each  object  to  allow  proper  construction  of  import  and  export  areas;  this 
should  be  quite  easy  to  accomplish  with  an  appropriately  conducted  domain  analysis.  But, 
given  dynamically  and  properly  constructed  import  and  export  areas,  how  should  they  be 
implemented  and  accessed  to  support  the  spirit  of  the  OCU  model? 

There  are  several  options  for  implementing  import /export  areas  and  their  access 
functions.  They  include: 

•  Global  Export  Areas:  All  data  which  is  to  be  made  available  externally  to  other 
primitive  objects  is  stored  in  a  single,  global  area,  similar  to  a  FORTRAN  common 
area.  When  a  primitive  object  requires  external  data,  it  is  obtained  directly  from 
this  common  export  area. 

This  method,  although  easy  to  implement,  violates  the  spirit  of  the  OCU  model, 
which  clearly  intends  import  and  export  areas  to  be  localized  within  subsystems  and 
to  serve  as  the  sole  interface  between  primitive  objects  and  the  external  data  they 
require. 

•  Pre-Execution  Data  Retrieval  or  “Latching”:  Each  subsystem  has  its  own  local  im¬ 
port  and  export  areas.  Immediately  before  a  subsystem  is  executed,  all  required 
external  data  is  retrieved  from  appropriate  export  areas  and  copied  into  its  import 
area;  the  subsystem  can  then  provide  the  data  from  its  own  import  area  when  a 
request  is  made  for  external  data. 

This  approach  certainly  conforms  to  the  OCU  model  description  and  ensures  that  all 
imported  values  are  temporally  consistent.  However,  this  method  has  a  potentially 
serious  drawback:  external  data  produced  during  a  subsystem’s  execution  cannot 
be  used  in  the  same  execution  cycle  by  other  primitive  objects  within  the  same 
subsystem.  This  may  be  (and  most  likely,  is)  too  restrictive,  considerably  limiting 
the  range  of  meaningful  applications  which  can  be  created. 

•  Point-of-Use  Retrieval:  Like  the  option  described  above,  this  method  provides  each 
subsystem  with  its  own  local  import  and  export  areas.  Unlike  the  earlier  approach. 
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however,  external  data  is  retrieved  as  it  is  requested.  This  retrieval  can  be  accom¬ 
plished  by  the  import  area,  which  supplies  the  data  directly  to  the  requesting  object 
with  no  involvement  by  other  elements  of  the  subsystem. 

This  approach  also  conforms  to  the  OCU  model  description  which  allows  “objects  to 
access  the  import  area’s  procedures  directly”  (24:19).  It  allows  for  very  flexible  sub¬ 
system  construction,  as  external  data  produced  by  one  object  within  the  subsystem 
can  be  imported  to  another  object  in  the  same  subsystem  in  a  pipeline-type  manner. 
Certain  temporal  restrictions  on  the  data  (i.e.,  a  value  must  be  exported  before  it 
can  be  used  as  an  import)  can  be  accommodated  by  judicious  specification  of  the 
application/subsystem.  This  is  the  approach  which  will  be  used  in  this  application. 

4-3  Goals/Objectives  for  the  Application  Composer  Implementation 

The  design  of  the  application  composer  was  influenced  by  the  following  goals /objectives: 

•  The  implemented  code  should  be  domain-independent;  domain-specific  information 
should  exist  only  in  a  technology  base. 

•  An  application  should  be  expressible  in  domain-oriented  terms  as  much  as  possible; 
computer  software  terminology  and  conventions  should  be  kept  to  a  minimum. 

•  An  application  definition  should  consist  of  an  application  executive,  in  addition  to 
appropriate  subsystem  and  primitive  object  components. 

•  A  primitive  object’s  mission  is  encapsulated  within  its  update  function.  Subsystem 
and  application  executive  missions  should  be  specified  by  the  user  -  any  automat¬ 
ically  generated  mission  would  lack  the  flexibility  required  to  adequately  describe 
all  possible  missions  for  all  possible  domains.  However,  certain  patterns  of  control 
may  be  identified  for  particular  domains  and  may  be  applicable  to  a  wide  range  of 
subsystem/executive  missions.  Identification  and  implementation  of  such  patterns  of 
control  are  left  for  future  research. 

•  Alternative  flows  of  control  should  be  available  for  use  in  specifying  application  execu¬ 
tive  and  subsystem  missions  -  sequential  flow  of  control  places  too  great  a  limitation 
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on  mission  specification.  Therefore,  IF-THEN-ELSE  and  DO-WHILE  constructs 
must  be  allowed.  Further,  variables  must  be  allowed  in  if/while  conditions  to  allow 
meaningful  conditions  to  be  specified. 

•  The  application  specialist  should  not  be  required  to  specify  what  external  data  is 
required  by  and  produced  by  the  primitive  objects  within  his  application.  This  in¬ 
formation  is  already  available  to  the  application  composer  as  a  by-product  of  domain 
analysis  and  should  reside  in  the  technology  base. 

•  Objects  and  subsystems  should  be  unaware  of  the  source  of  external  data,  where  it 
is  used,  how  it  is  stored,  etc.  This  knowledge  should  be  localized  within  import  and 
export  areas. 

•  External  data  needed  by  a  primitive  object  should  be  retrieved  as  needed,  not  ob¬ 
tained  en  masse  prior  to  subsystem  execution.  This  allows  a  primitive  object  to  use 
data  just  produced  by  another  object  within  the  same  subsystem.  With  this  retrieval 
scheme,  there  is  no  need  to  store  retrieved  data  in  the  import  area;  it  can  be  passed 
along  directly  to  the  requesting  object. 

•  The  application  specialist  should  reference  imported  and  exported  data  by  name. 
This  also  pertains  to  identifiers  in  conditional  expressions,  as  it  has  been  established 
that  they  reference  import /export  items. 

•  The  application  specification  shoJild  be  complete  before  its  behavior  is  simulated. 
Therefore,  all  import-to-export  connections  must  be  established  before  the  applica¬ 
tion  is  executed.  If  more  than  one  export  datum  can  provide  the  information  needed 
by  an  import,  the  application  specialist  must  be  prompted  to  select  the  appropriate 
one.  If  the  application  specialist  truly  does  not  care  where  the  imported  data  comes 
from,  he  should  be  able  specify  that  an  appropriate,  arbitrary  source  be  used.  These 
import-to-export  connections  are  static;  they  are  a  fundamental  aspect  of  the  appli¬ 
cation  specification  and  are  not  changed  dynamically  during  application  execution. 

4.4  Conventions  Used  in  this  Implementation 

The  following  conventions  are  used  throughout  the  application  composer: 


4-14 


4-4-i  Conventions  For  the  Software  Engineer 

•  All  primitive  objects  have  been  correctly  defined  using  the  primitive  object  template 
described  in  Appendix  A. 

•  All  coded  primitive  object  attribute/variable  names  are  prefixed  by  the  object’s  ob¬ 
ject  class.  For  example:  COUNTER-OBJ-COUNT  -  represents  an  attributed  named 
COUNT  which  applies  to  objects  of  the  class,  COUNTER-OBJ.  This  scheme  ensures 
that  attribute/variable  names  are  unique  throughout  the  domain  and  presents  a  more 
domain-oriented  (rather  than  programmer-oriented)  “feel”  to  the  application  speci¬ 
fication. 

•  All  update  function  names  begin  with  the  object  class.  Example;  COUNTER-OBJ- 
UPDATEl  is  the  name  of  the  update  function,  UPDATEl,  which  is  applicable  to 
primitive  objects  of  the  class  COUNTER-OBJ. 

4.4-2  Conventions  for  the  Application  Specialist 

•  The  application  specialist,  when  referencing  update  function  names  and  coefficients 
in  setf  unction  statements  and  attributes  in  setstate  statements,  specifies  only  the 
unqualified  name.  For  example,  the  application  specialist  would  specify 

setfunction  counterl  updatel 

to  set  COUNTERl’s  update  function  to  COUNTER-OBJ-UPDATEl  and 

setstate  counterl  (count,  2) 

to  set  COUNTERl’s  COUNTER-OBJ-COUNT  attribute  to  2.  This  scheme  allows 
the  application  specialist  to  use  more  domain-oriented  (rather  than  programmer- 
oriented)  terms  and  frees  him  from  concern  about  object  class  names  while  preserving 
attribute  name  uniqueness  throughout  the  domain. 
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4-5  Data  Structures  to  Support  this  Implementation 

The  data  structures  chosen  to  represent  the  data  in  a  software  system  and  the  pro¬ 
gramming  language  in  which  the  code  is  written  profoundly  affect  the  system’s  implemen¬ 
tation.  For  this  implementation,  we  have  selected  the  REFINE  language  and  its  grammar 
processing  facility,  DIALECT.  This  choice  virtually  dictates  Architect’s  fundamental  data 
structure:  an  abstract  syntax  tree.  It  also  strongly  encourages  an  object-oriented  approach, 
as  DIALECT  relies  heavily  upon  objects  in  its  processing. 

Figure  4.3  illustrates  the  hierarchy  of  object  classes  developed  for  this  implementa¬ 
tion.  USER-OBJECT,  the  highest  level  object  in  the  REFINE  object  class  hierarchy,  is  the 
implied  parent  of  each  of  the  boxed  object  classes  in  the  figure;  this  parent  relationship  has 
been  omitted  to  allow  all  other  meaningful  relationships  to  be  presented  in  one  diagram. 
Figure  4.4  illustrates  the  attributes  of  each  object  class;  for  more  detailed  and  technical 
information  about  these  object  class  attributes,  refer  to  the  REFINE  code  in  Appendix  D. 

4.6  Summary 

This  chapter  presented  an  overview  of  the  high-level  design  of  Architect,  the  ap¬ 
plication  composition  system  which  was  introduced  in  Chapter  3.5.  Architect  is  heavily 
dependent  on  the  software  architecture  used  to  produce  its  compositions;  therefore,  the 
selected  architecture  (the  OCU  model)  was  briefly  discussed,  as  were  various  adaptations 
which  were  made  for  this  implementation.  In  addition,  the  goals/objectives  of  this  appli¬ 
cation  composer  implementation  were  enumerated.  Lastly,  several  conventions  and  data 
structures,  which  are  used  throughout  the  system,  were  presented. 
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Statement-Ob 
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Spec-Obj 

^ —  Spec-Parts 


Application-Obj 


t  Application-Components 
Application-Update 


Call-Obj 


L_ 


Operand 


Create-Call-Obj 

t  operand  (Inherited) 
Object-Type 

SetState-Call-Obj 

t  operand  (Inherited) 
Stale-Changes 


SetFunction-CallObj 

—  operand  (Inherited) 
—  Function-Name 
' —  Coefficients 


If-Stmt-Obj 


If-Cortd 

Then-Stmts 

Else-Stmts 


While-Stmt-Obj 

tWhile-Cond 
While-Stmts 


Import-Obj 

-  Import-Name 

-  Import-Category 

-  Import-Type-Data 

t  Consumer 
Source 


Unary-Expression 

Argument 


Binary-Expression 

tArgumenti 
Argumenl2 


Subsystem-Obj 

—  Controllees 
—  Import-Area 
—  E)^rt-Area 
—  U^ate 
—  Initialize 


Name-Value-Obj 


t  Name-Value-Name 
Name-Value-Value 


Source-Obj 

—  Source-Subsystem 
—  Source-Object 
' —  Source-Name 


Export-Obj 


—  Export-Name 

—  Exjxjrt-Calegory 

—  Export-Type-Data 

—  Value 

—  Producer 


Boolean-Literal 


Real-Literal 


Real-value 


Identifier 


t  Id-Name 
Id-Source 


String-Literal 

I —  String-Value 


I —  Boolean-Value 

Integer-Literal 

I —  Int-Value 


Figure  4.4.  Object  Class  Attribute  Maps 
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V.  Detailed  Software  Design 


This  chapter  presents  a  detailed  design  of  the  Preprocess,  Semantic  Checks  and  Ex¬ 
ecute  portions  of  Architect,  the  application  composition  system  introduced  in  Section  3.5. 
It  elaborates  on  the  high-level  design  of  these  major  functions  discussed  in  Section  4.1, 
meets  the  implementation’s  goals/objectives  (reference  Section  4.3),  and  conforms  to  the 
conventions  identified  in  Section  4.4. 

5.1  Preprocess  the  Application 

After  the  application  is  entirely  defined,  the  structured  object  base  contains  “com¬ 
plete”,  fully-instantiated  components  (from  the  application  specialist’s  viewpoint).  How¬ 
ever,  some  critical  data  needed  for  further  processing  may  not  yet  be  specified;  preprocess¬ 
ing  the  application  obtains  such  data  from  available  system  knowledge,  making  it  accessible 
in  a  more  usable  form  and,  thus,  “completing”  the  specification.  Two  examples  of  such 
critical,  as-yet-unavailable  data  are  subsystem  import  areas/export  areas  and  the  source 
of  identifiers  used  in  if  and  vhile  statements  in  subsystem  update  procedures. 


Figure  5.1.  Preprocess  Application 


A  structure  chart  representing  the  preprocessing  activity  is  presented  in  Figure  5.1. 
Preprocessing  is  not  an  inherent  requirement  for  all  application  composers;  it  evolved  as 
a  requirement  for  this  application  composer  due  to  our  selection  of  the  OCU  architectural 
model  as  its  basis.  Because  it  may  not  be  required  for  a  different  application  composer 
implementation,  preprocessing  should  be  transparent  to  the  application  specialist;  that  is. 
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he  should  be  virtually  unaware  of  its  existence.  Therefore,  although  it  is  conceptually  a 
stand-alone  component  of  this  implementation,  preprocessing  has  been  incorporated  into 
the  semantic  check  component. 

5.1.1  Building  Import  and  Export  Areas  The  contents  of  an  import  area  depend 
upon  the  external  data  (input-data)  needed  by  all  the  primitive  objects  which  are  con¬ 
trolled  by  that  subsystem;  likewise,  a  subsystem’s  export  area  depends  upon  the  data 
(output-data)  produced  by  all  its  primitive  objects  which  must  be  made  available  to  other 
subsystems/objects.  In  keeping  with  our  goal  of  constraining  application  specification  to 
domain-oriented  rather  than  programmer-oriented  terms,  an  application  specialist  should 
not  be  required  to  specify  the  contents  of  import  and  export  areas  of  the  subsystems  in 
his  application.  Moreover,  input-data  and  output-data  for  each  class  (or  type)  of  primitive 
object  are  available  in  the  technology  base  as  a  consequence  of  domain  analysis.  Therefore, 
the  appropriate  data  for  each  import  area  and  export  area  can  be  generated  automatically, 
given  a  list  of  the  primitive  objects  which  comprise  the  subsystem  (the  controls  clause 
serves  as  such  a  list).  This  automatic  generation  of  import  and  export  areas  is  accomplished 
via  preprocessing. 

Figure  5.2  illustrates  this  process  of  automatically  “building”  the  import  and  ex¬ 
port  areas.  The  upper  portion  of  the  figure  represents  a  subsystem  before  preprocessing 
is  accomplished.  Note  that  its  objects  “contain”  input-data  and  output-data  but  that  the 
import  and  export  areas  are  empty  (input-data  can  be  distinguished  by  the  partitioning  of 
its  rightmost  segment  into  three  horizontal  parts;  this  will  be  explained  later).  Preprocess¬ 
ing  the  subsystem  transforms  it  into  the  representation  at  the  bottom  of  the  figure.  Note 
that  all  input-data  for  all  objects  within  the  subsystem  have  been  copied  to  the  import 
area  and  all  output-data  to  the  export  area.  Also,  note  that  the  consumer  object  name 
and  producer  object  name  have  been  added  to  import  items  and  export  items,  respectively 
(in  the  box,  second  from  the  right). 

5. 1.1.1  BUILD-IMPORT-EXPORT-AREA  Each  subsystem  in  an  applica¬ 
tion  definition  is  examined.  For  each  input  data  item  for  each  primitive  object  controlled 
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Figure  5.2.  Build  Import /Export  Areas 
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L»y  the  subsystem,  an  entry  is  made  in  the  subsystem’s  import  area;  likewise  with  output 
data  and  the  export  area. 

5.1.2  Determining  the  Source  for  Imports  Merely  specifying  the  contents  of  im¬ 
port/export  areas  is  inadequate  to  complete  the  application’s  specification  with  respect  to 
external  data  requirements.  Under  the  OCU  model,  a  primitive  object’s  request  for  a  piece 
of  external  data  (i.e.,  an  import  area  entry)  is  satisfied  by  retrieving  the  appropriate  data 
from  an  export  area  in  some  subsystem  within  the  application.  To  complete  the  specifica¬ 
tion,  these  connections  between  each  item  in  an  import  area  and  the  export  item  which  is 
to  provide  its  data  must  be  made.  In  other  words,  the  source  of  the  data  for  each  import 
item  must  be  specified.  This,  too,  is  accomplished  via  preprocessing. 

When  an  import  can  be  satisfied  by  only  one  export  item  (see  Section  5.1.3),  its 
source  can  be  automatically  determined  without  user  involvement.  This  is  illustrated  in 
Figure  5.3.  INI,  which  is  needed  by  OBJ2,  and  IN2,  which  is  required  by  OBJl,  are  both 
of  type  CAT2;  only  OUTl,  which  is  produced  by  0BJ2,  can  provide  this  type  of  data. 
Therefore,  OUTl  must  be  the  source  for  these  imports.  The  subsystem  name,  producing 
object  name,  and  output-data  name  of  the  source  export  item  appear  from  top  to  bottom 
in  the  import  item’s  rightmost  segment. 


Import  Area  Export  Area 


Figure  5.3.  Determine  Import  Sources  -  Part  1 


However,  the  source  of  an  import  which  can  be  satisfied  by  more  than  one  export 
item  can  not  be  determined  automatically;  the  application  specialist  must  indicate  which 
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potential  source  should  be  used.  Figure  5.4  represents  the  state  of  the  import  area  after 
the  following  source  determination  dialogue  has  taken  place; 


More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  OBJl 
in  subsystem  SUBl 

Choose  the  export  item  (subsystem  and  component) 
that  you  wish  to  be  the  source  of  this  data: 

1>  subsystem  "SUBl"  component  "OBJl"  name  "OUTl" 

2>  subsystem  "SUBl"  component  "0BJ2"  name  "0UT2" 

Enter  the  niimber  corresponding  to  the  source  you  want  to  use 
2 


Import  Area 


Export  Area 


Figure  5.4.  Determine  Import  Sources  -  Part  2 


Note;  these  import-to-export  connections  can  be  made  only  after  all  import /export 
areas  have  been  constructed  to  ensure  that  all  exports  are  considered  as  possible  import 
sources. 

5. 1.2.1  DETERMINE-IMPORT-SOURCES  Each  item  in  the  import  area  of 
each  subsystem  in  the  application  definition  is  examined.  If  a  source  has  not  yet  been 
specified  for  that  import,  the  export  areas  of  all  subsystems  in  the  application  are  searched 
for  export  items  which  could  provide  the  needed  data.  Only  export  items  which  are  of 
the  same  data  category  as  the  import  item  can  be  considered  as  potential  sources.  If 
only  one  export  item  produces  data  of  the  proper  category  to  satisfy  an  import  item,  it 
is  automatically  identified  as  the  source.  If  more  than  one  export  item  could  provide  the 
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required  data,  the  application  specialist  is  prompted  to  select  the  appropriate  source  from 
a  list  of  possible  choices,  which  includes  a  “use  an  arbitrary  one”  option  (to  be  used  if  the 
application  specialist  doesn’t  care  where  the  data  comes  from;  it  is  anticipated  that  this 
will  be  rarely  used).  If  a  source  has  been  previously  specified  for  the  import  item,  it  should 
be  displayed  to  the  application  specialist,  who  may  select  a  different  source  at  this  time, 
if  desired. 

5.1.3  Import/Export  Considerations  The  following  questions  or  considerations  arose 
during  different  phases  of  this  design  and  its  implementation.  When  feasible,  a  rapid  proto¬ 
type  was  constructed  to  answer  these  questions  and  to  test  various  alternatives.  There  were 
two  underlying  principles  which  dictated  the  choices  made  in  answering  these  questions: 
allow  maximum  flexibility  for  application  specification  and  free  the  application  specialist 
from  implementation  details  as  much  as  possible. 

1.  How  are  the  external  data  needed  by  and  produced  by  a  primitive  object  known? 
One  aspect  of  domain  analysis  is  to  determine  what  external  information  (INPUT- 
DATA)  is  needed  to  adequately  process  (update)  each  class  of  primitive  object  and 
what  information  must  be  made  available  externally  to  other  objects  (OUTPUT- 
DATA).  Implicit  in  determining  each  required  INPUT-DATA  and  OUTPUT-DATA 
is  the  identification  of  its  name,  category,  and  basic  data  type.  Because  INPUT- 
DATA  and  OUTPUT-DATA  are  the  same  for  each  object  instance  in  a  particular 
object  class,  this  information  can  be  pre-stored  in  the  technology  base  and  is  therefore 
available  to  be  incorporated  automatically  into  each  newly  created  object  of  that 
class. 

2.  Does  each  instance  of  a  primitive  object  import  the  same  value  for  a  given  variable 
name?  It  seems  likely  that  different  object  instances,  which  require  external  data 
with  the  same  name,  may  actually  wish  to  obtain  that  data  from  different  sources. 
Therefore,  only  one  entry  in  the  import  area  for  each  required  external  variable  name 
is  insufficient;  the  name  of  the  requesting  object  must  be  maintained  as  well  to  ensure 
that  each  primitive  object’s  external  data  request  accesses  the  correct  import  item. 
When  a  piece  of  external  data  is  required  by  a  primitive  object  update  function, 
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both  the  requested  variable  name  and  requesting  object’s  name  (consumer)  must 
be  matched  to  ascertain  the  correct  import  area  entry  to  be  used  in  obtaining  the 
appropriate  requested  data. 

3.  Does  a  subsystem  export  only  one  value  per  variable  name?  Just  as  it  was  likely 
that  different  object  instances  may  obtain  INPUT-DATA  with  the  same  name  from 
different  sources,  it  is  also  likely  that  more  than  one  object  in  a  subsystem  may 
produce  external  data  with  the  same  variable  name.  Therefore,  one  entry  in  the 
export  area  per  variable  name  is  insufficient;  the  producing  object’s  name  (producer) 
must  be  maintained  as  well  as  the  variable  name  and  its  associated  value.  When 
data  is  to  be  stored  into  the  export  area,  both  variable  name  and  producer  name 
must  be  matched  to  ensure  that  the  correct  export  item  is  used. 

4.  How  does  an  object  obtain  the  external  data  that  it  requires?  External  data  is 
requested  via  a  GET-IMPORT  call  whose  parameters  include  the  name  of  the  data  to 
be  obtained  as  well  as  the  names  of  the  requesting  primitive  object  and  its  subsystem. 
GET- IMPORT  finds  the  appropriate  import  item  within  the  subsystem’s  import  area 
which  corresponds  to  this  request  and  uses  its  previously  specified  source  information 
to  directly  obtain  the  needed  data. 

5.  What  is  “source  information?”  It  represents  a  connection  between  an  import  item 
and  the  export  item  within  the  application  which  supplies  the  data  to  be  imported. 
Source  information  consists  of  the  name  of  the  subsystem  in  whose  export  area  the 
“source”  export  item  can  be  found,  the  name  of  the  primitive  object  which  produces 
that  data,  and  the  name  of  the  data  itself.  This  information  uniquely  describes  the 
export  item  from  which  the  imported  data  is  to  be  retrieved. 

6.  How  does  an  export  item  qualify  as  the  source  of  an  import  item?  Each  piece  of 
external  data  (both  imports  and  exports)  has  a  name,  a  data  category  and  a  data 
type.  Together  with  the  subsystem  name  and  the  name  of  the  consumer/producer 
object,  the  name  provides  a  means  to  uniquely  identify  an  import  or  export  item. 
The  data  type  indicates  the  item’s  primitive  data  type  (integer,  real,  boolean,  string 
or  .symbol);  this  is  used  when  dealing  with  identifiers  in  conditional  expression.®. 
The  data  category  indicates  the  class  of  the  data,  in  domain-oriented  terms.  For 
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example,  an  import  might  be  expecting  a  real  number  (data  type)  but  its  category 
may  be  water-temperature  or  air-pressure  or  interest-rate,  etc.,  depending  on  the 
requirements  of  the  domain.  Only  those  export  items  which  are  of  the  same  data 
category  can  be  potential  sources  for  the  import.  This  scheme,  in  effect,  creates 
user-defined,  domain-dependent  data  subtypes  (very  similar  to  Ada  subtypes)  which 
serve  to  constrain  the  possible  data  choices.  In  the  previous  example,  although 
export  items  representing  water-temperature,  air-pressure  and  interest-rate  may  all 
be  real  numbers,  only  the  water-temperature  export  can  serve  as  the  source  for  a 
water-temperature  import.  In  the  current  implementation,  data  category  and  data 
type  are  related;  all  imports/exports  of  a  given  category  are  assumed  to  be  of  the 
same  underlying  data  type.  If  this  later  becomes  too  restrictive,  conversion  functions 
may  be  required  to  allow  disparate  data  types  (e.g.,  integer  and  real)  to  be  used 
interchangeably  within  a  data  category. 

7.  What  if  more  than  one  subsystem  and/or  object  produces  external  data  which  qual¬ 
ifies  as  the  source  of  an  import  item?  If  more  than  one  subsystem/object  produces 
data  which  can  satisfy  the  request,  the  application  specialist  is  prompted  to  indicate 
which  data  should  be  used  to  satisfy  the  request  rather  than  allowing  the  system  to 
choose  arbitrarily.  However,  after  the  appropriate  source  is  specified  for  a  particular 
request,  the  system  should  not  prompt  the  user  again  if  the  same  data  is  later  re¬ 
quested  by  the  same  object;  it  should  “remember”  which  subsystem /object  produced 
the  requested  data  and  access  it  directly.  To  allow  the  system  to  “remember”  such 
information,  source  subsystem  name  and  source  object  name  are  stored  in  the  import 
area  in  addition  to  the  source’s  variable  name. 

8.  What  if  the  application  specialist  doesn’t  care  where  the  requested  data  is  obtained? 
If  only  one  export  item  can  provide  the  requested  data,  it  obviously  should  be  used 
as  the  data  source.  If  more  than  one  export  item  may  produce  the  data,  the  system 
should  allow  the  application  specialist  to  use  an  arbitrary  source  if  any  data  of  the 
proper  category  will  suffice.  The  “arbitrary  source”  option  is  provided  in  addition 
to  the  specific  subsystem/object  choices  discussed  previously.  If  the  application  spe¬ 
cialist  selects  the  arbitrary  source  option,  all  future  requests  for  the  same  data  by 
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the  same  subsystem  will  be  satisfied  by  the  selection  of  an  arbitrary  source  which 
satisfies  the  data  category  requirement. 

9.  When  an  application  is  edited,  what  happens  to  the  import  and  export  areas  of  its 
subsystems?  The  edit  process  can  change  any/all  of  the  components  already  in  the 
application  and  can  also  add/delete  objects  to/from  the  application.  Adding/deleting 
objects  from  subsystems  will  likely  change  import  and/or  export  areas;  therefore,  pre¬ 
processing  must  be  reaccomplished  after  each  edit  step.  To  ensure  that  preprocessing 
is  accomplished,  a  new-data  flag  is  set  each  time  the  edit  process  is  initiated.  If  the 
new-data  flag  is  set,  preprocessing  and  semantic  checks  must  be  reaccomplished  on 
the  entire  application  specification  before  its  behavior  can  be  simulated.  During 
preprocessing,  import  items  are  added  to  the  subsystem’s  import  area  if  there  are 
currently  no  import  items  for  a  primitive  object  and  likewise  for  the  export  area;  this 
ensures  that  import /export  areas  are  consistent  for  added  subsystem  components.  A 
“clean-up”  operation  is  also  conducted.  Any  import  item  used  by  a  primitive  ob¬ 
ject  which  is  no  longer  part  of  the  subsystem  is  removed  from  the  import  area,  and 
likewise  for  the  export  area;  this  ensures  that  import /export  areas  are  consistent  for 
deleted  subsystem  components. 

5.1.4  Determining  the  Source  of  Variables  in  Conditions  If  and  while  statements 
within  a  subsystem  update  procedure  provide  the  necessary  flexibility  which  enables  aa 
application  specialist  to  precisely  specify  the  required  mission  for  any  subsystem.  Each  of 
these  statements  includes  a  conditional  expression,  the  result  of  whose  evaluation  deter¬ 
mines  how  the  statement  will  be  executed.  In  general,  meaningful  conditional  expressions 
include  some  variable  data  whose  value  changes  during  the  current  execution  cycle  or  from 
one  execution  cycle  to  the  next.  During  specification,  the  application  specification  merely 
provides  a  name  or  identifier  for  this  variable  data.  To  complete  the  specification,  this 
identifier  must  be  associated  with  the  data  to  which  it  refers.  The  only  data  directly 
available  to  the  subsystem’s  update  procedure  resides  in  its  import  and  export  areas; 
therefore,  the  identifier  must  be  found  in  one  of  these  areas. 
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5. 1.4-1  DETERMINE-SOURCES-FOR~CONDITIONALS  Each  identifier  in 
each  subsystem  update  procedure  in  an  application  definition  is  examined.  If  the  identifier 
has  not  yet  been  associated  with  its  corresponding  data,  the  subsystem’s  import  and  export 
areas  are  searched  to  find  potential  association  candidates.  If  there  is  only  one  possible 
candidate,  use  it  as  the  identifier’s  source;  if  there  are  multiple  potential  candidates,  present 
the  list  to  the  application  specialist  who  must  select  the  appropriate  one.  No  possible 
candidates  indicates  a  specification  error.  If  the  identifier/data  association  has  already  been 
accomplished,  the  application  specialist  is  notified,  presented  with  the  current  association, 
and  may  select  a  different  association,  if  desired. 

5.1.5  Considerations  for  Variables  in  Conditional  Expressions  As  with  the  im¬ 
port/export  area  considerations,  these  questions  concerning  variables  or  identifiers  in  IF 
and  WHILE  conditional  expressions  had  to  be  resolved  before  the  design  and  implemen¬ 
tation  could  be  realized. 

1 .  What  variable  data  (identifiers)  can  be  used  in  the  conditional  expressions  of  if  and 
while  statements  in  subsystem  update  procedures?  Identifiers  must  be  recognized 
by  and  available  to  the  subsystem  in  whose  update  procedure  they  appear.  The 
OCU  model  does  not  provide  a  mechanism  for  a  subsystem  to  directly  access  any  of  its 
primitive  objects’  current-state  data.  The  only  data  available  to  a  subsystem  resides 
in  its  import  and/or  export  areas.  Therefore,  an  identifier  can  only  be  associated  with 
an  import  or  export  item.  The  application  specialist  specifies  the  identifier  by  name; 
if  an  import  or  export  item  has  the  same  name,  it  is  a  candidate  for  association.  A 
specification  error  occurs  if  there  are  no  candidates  within  the  subsystem. 

2.  How  do  you  know  that  conditional  expressions  involving  identifiers  are  valid  (i.e., 
that  you  aren’t  trying  to  compare  apples  and  oranges)?  Each  import  and  export 
item  has  a  “data- type”  which  corresponds  to  a  REFINE  primitive  data  type  (e.g., 
integer,  real,  string,  etc).  It  is  used  to  ensure  that  conditional  expressions  can  be 
evaluated  in  a  meaningful  way. 

3.  If  several  imports  and/or  exports  within  a  subsystem  have  the  same  name,  how  does 
the  system  (and  application  specialist)  determine  which  one  applies  to  each  variable 
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used  in  the  conditional?  As  with  determining  the  sources  for  imports,  Architect 
first  finds  all  possible  candidates  (i.e.,  imports  and  exports  with  the  same  name  as 
the  conditional  vajiable).  If  only  one  item  meets  that  criteria,  it  is  obviously  the 
intended  source  and  Architect  automatically  makes  the  connection.  If,  however, 
there  are  multiple  possible  sources,  the  system  prompts  the  user  to  select  the  desired 
source  from  the  a  list  of  alternatives.  The  user  may  by-pass  this  source  determination 
dialogue  by  “qualifying”  the  variable  name(s)  in  the  conditional.  This  is  achieved  by 
prefacing  the  variable  name  with  the  object  which  produces/ consumes  that  item  (this 
assumes  that  imports  and  exports  for  the  same  object  type  do  not  share  common 
names).  For  example,  if  a  variable  in  a  condition  refers  to  the  import  item  named  INI 
which  is  consumed  by  OBJl,  the  user  woidd  specify  the  qualification  as  OBJl.INl. 
After  sources  for  conditionals  have  been  determined,  it  is  impossible  to  differentiate 
between  qualified  and  unqualified  variables. 

5.2  Perform  Semantic  Checks 

Two  levels  of  semantic  checks  exist  in  Architect.  Architecture-oriented  semantic 
checks  ensure  that  the  proposed  application  specification  conforms  to  the  composition  re¬ 
quirements  of  the  OCU  model  and  that  its  behavior  can  be  successfully  simulated  (e.g., 
all  components  exist  in  the  object  base,  application/subsystem  update  procedures  directly 
reference  only  components  which  are  part  of  the  same  application/subsystem,  data  input  to 
one  subsystem  is  produced  as  output  by  some  subsystem  in  the  application,  etc.).  Domain- 
specific  semantic  checks  are  knowledge-based,  building  on  what  is  known  about  the  domain, 
its  objects,  and  previous  applications  created  in  that  domain,  to  assist  the  application  spe¬ 
cialist  in  composing  a  meaningful  and  optimized  application.  This  research  effort  currently 
includes  only  architecture-oriented  semantic  checks;  domain-specific  semantic  checks  are 
presently  being  investigated  by  Captain  Mark  Gerken,  an  AFIT  doctoral  student. 

After  preprocessing  has  been  completed,  architecture  semantic  checks  are  performed. 
These  semantic  checks  embody  the  constraints  imposed  on  the  composition  of  applications 
within  the  framework  of  the  selected  architecture  model  (in  this  case,  the  OCU  model). 
They  are  derived  solely  from  the  structure  of  the  architecture  model  and  are  domain- 
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independent.  Each  semantic  check  is  encapsulated  into  a  REFINE  function;  these  functions 
are  executed  via  an  appropriate  sequence  of  function  calls.  Domain-specific  semantic  checks 
are  completed  after  the  proposed  application  successfully  passes  the  architecture  semantic 
checks. 


Figure  5.5.  Semantic  Checks 


5.2.1  Architecture  Semantic  Checks  Meaningful  architecture  semantic  checks  can 
be  performed  on  the  entire  application  and  its  constituent  subsystems.  There  are  currently 
no  meaningful  semantic  checks  for  primitive  objects;  Architect  assumes  that  primitive 
object  class  definitions  and  update  procedures  have  been  correctly  constructed  by  the 
software  engineer.  A  structure  chart  for  processing  semantic  checks  appears  in  Figure  5.5. 

Architecture  semantic  errors  describe  conditions  that  preclude  successful  behavior 
simulation  of  the  application  or  present  an  unacceptable  inconsistency  which  can  not  be 
successfully  resolved  without  human  intervention.  Warnings,  on  the  other  hand,  represent 
apparent  inconsistencies  in  an  application  specification  which  may  actually  presage  a  com- 
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position  error  but  do  not  preclude  behavior  simulation.  However,  they  should  be  carefully 
considered  by  the  application  specialist  before  proceeding.  The  semantic  checks  in  this 
implementation  generate  either  errors  or  warnings,  as  appropriate. 


5. 2. 1.1  Global  Application  Specification  Semantic  Checks  The  following  checks 
are  conducted  on  the  entire  proposed  application  specified  by  the  application  specialist. 

1.  Each  application  specification  must  contain  one  and  only  one  application  executive 
object.  An  example  of  a  very  simple  application  object  is: 

application  application!  is 

controls :  subsystem! ,  subsystem2 
update  procedure: 

update  subsystem! 
update  8ubsystem2 

2.  An  instance  of  a  primitive  object  can  be  part  of  only  one  subsystem  within  an  ap¬ 
plication.  This  restriction  is  necessary  to  ensure  the  integrity  of  each  subsystem. 
Only  activities  within  the  subsystem  (and  their  inputs)  affect  the  operation  of  the 
subsystem;  the  states  of  the  objects  which  comprise  a  subsystem  are  changed  only 
by  executing  the  subsystem’s  update  procedure.  An  object  instance  which  is  part 
of  two  or  more  subsystems  could  cause  spurious  results  because  its  state  would  be 
determined  by  multiple  subsystems. 

3.  Each  application  specification  must  contain  all  those  (and  only  those)  components 
needed  to  compose  the  application.  Unused  subsystems  (not  included  in  an  appli¬ 
cation’s  controls  clause  nor  incorporated  into  any  other  subsystem)  and  primitive 
objects  (not  included  in  any  subsystem’s  controls  clause)  may  indicate  an  oversight 
by  the  application  specialist  -  perhaps  he  actually  intended  to  use  them  in  the  ap¬ 
plication  but  forgot  to  do  so.  If  this  anomalous  condition  is  discovered,  a  warning  is 
issued. 

5.2. 1.2  Application  Executive  Semantic  Checks  The  following  checks  are  con¬ 
ducted  on  each  application  executive  found  in  the  proposed  application  specification.  In 
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theory,  only  one  application  executive  exists  per  specification.  However,  in  an  effort  to 
provide  the  application  specialist  diagnostic  information  on  all  anomalies  at  the  earliest 
possible  phase,  all  application  executives  are  checked  in  this  manner. 

1.  CHECK-IF-APPLICATION-COMPONENTS- EXIST:  Subsystems  listed  in  the  con¬ 
trols  clause  must  already  exist  (i.e.,  be  specified  in  the  application  definition).  Note: 
although  the  OCU  model  allows  for  dynamic  creation  of  subsystems  via  an  initialize 
operation,  there  are  several  unaddressed  issues  regarding  dynamic  initialization,  and 
it  has  not  yet  been  included  in  this  implementation. 

2.  CHECK-FOR-DIRECT-USE-OF-PRIMITIVES:  Only  subsystems  and  subsystem  pro¬ 
cedural  interfaces  may  be  referenced  in  an  application’s  controls  clause  and  update 
procedure;  direct  reference  to  primitive  objects  is  not  allowed.  It  is  unclear  whether 
the  OCU  model  itself  allows  arbitrary  primitive  objects  to  be  included  directly  in  an 
application  executive;  certainly,  such  statements  as  “the  OCU  has  most  effectively 
been  applied  when  the  software  system  under  development  can  be  described  as  a 
set  of  subsysivjms”  (24:17)  imply  the  contrary.  From  an  implementation  viewpoint, 
several  unresolved  issues  regarding  application  executives  (e.g.,  do  they  have  facili¬ 
ties  similar  to  import/export  areas  and,  if  so,  how  should  they  work?  Is  it  desirable 
to  have  special,  primitive  objects  for  executives?)  currently  preclude  the  direct  use 
primitive  objects. 

3.  CHECK-APPLICATION-UPDATE-PROCEDURE:  At  this  time,  only  caU  state¬ 
ments  (i.e.,  the  OCU  subsystem  update  procedural  interface)  are  valid  in  the  ap¬ 
plication  update  procedure.  If  and  while  statements  are  not  allowed  in  this  very 
simple  application  executive  implementation  because  no  appropriate  data  is  available 
from  which  to  construct  (and  evaluate)  meaningful  conditions.  Recall  that  condition 
variables  must  be  accessable  at  the  level  at  which  they  are  specified  and  that  there  is 
no  provision  in  the  OCU  model  to  query  a  subordinate  object  about  its  state  data. 
This  restriction  was  overcome  for  subsystems  by  associating  condition  variables  with 
import/export  items.  At  the  present  time,  no  import  or  export  areas  are  associated 
with  applications. 


•  CHECK-IF-OPERAND-IN-APPLICATION  Only  subsystems  included  in  the 
application’s  controls  clause  may  be  referenced  in  its  update  procedure.  This 
constraint  requires  the  application  specialist  to  carefully  consider  which  subsys¬ 
tems  are  needed  in  his  application  before  thinking  about  how  they  are  to  be 
composed.  It  also  allows  Architect  to  compare  the  controls  entries  against  the 
operands  in  the  update  procedure  as  a  consistency  “double  check.” 

•  CHECK-FOR-LEGAL-C ALL-STATEMENTS;  Currently,  only  the  update  in¬ 
terface  is  implemented  for  subsystems;  too  many  unresolved  issues  remain  to 
implement  the  remaining  subsystem  interfaces  (initialize,  stabilize,  configure 
and  destroy)  at  this  time.  However,  in  anticipation  that  future  research  efforts 
will  resolve  these  issues,  the  OCU  grammar  accepts  these  interfaces  as  valid 
keywords;  this  REFINE  function  ensures  that  no  attempt  is  made  to  actually 
execute  them. 

4.  CHECK-FOR-DUPES-IN-APPLICATION-COMPONENTS:  Is  an  application  com¬ 
ponent  listed  more  than  once  in  the  controls  clause?  Such  a  duplication  may  actu¬ 
ally  have  been  a  typographical  error  and  not  what  the  application  specialist  intended. 

A  warning  is  generated. 

5.  CHECK-FOR-UNUSED-SUBSYSTEMS-IN-UPDATE:  Are  there  any  subsystems  listed 
in  the  controls  clause  which  are  not  used  as  operands  in  the  application’s  update 
procedure?  Such  an  omission  may  have  been  an  oversight  and  additional  state- 
ment(s)  should  have  been  included  in  the  update  procedure  to  execute  these  sub¬ 
systems.  Or,  the  subsystem  in  question  may  have  been  included  in  the  controls 
clause  erroneously.  A  warning  is  generated. 

5. 2. 1.3  Subsystem  Semantic  Checks  The  following  checks  are  conducted  on 
each  subsystem  found  in  the  proposed  application  specification. 

1.  CHECK-IF-CONTROLLEES-EXIST:  Components  (subsystems  and  primitve  ob¬ 
jects)  listed  in  the  controls  clause  must  already  exist.  Note;  although  the  OCU 
model  does  allow  for  dynamic  creation  of  subsystems  via  an  initialize  operation  and 
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primitive  objects  via  the  create  interface,  there  are  several  unaddressed  issues  regard¬ 
ing  such  dynamic  creation;  therefore,  the  create  and  initialize  interfaces  have  not  yet 
been  incorporated  into  this  implementation. 

2.  CHECK-SUBSYSTEM-UPDATE-PROCEDURE:  AU  of  the  statements  within  the 
subsystem’s  update  procedure  must  be  examined  to  ensure  that  only  legal  actions 
are  specified.  Various  semantic  checks  are  executed,  depending  on  the  type  of  state¬ 
ment  encountered. 

•  CHECK-IF-STATEMENT:  If  conditions  must  be  valid  -  each  condition  must 
be  reduceable  to  a  boolean  expression,  all  identifiers  referenced  must  be  available 
in  the  subsystem’s  import  and/or  export  area,  data  types  within  the  condition 
must  be  compatible  with  each  other  and  with  the  operation  specified  (e.g.,  arith¬ 
metic  operations  can  not  be  performed  on  data  of  type  STRING).  In  addition, 
all  the  statements  within  the  if  statement  (both  the  then  and  else  clauses) 
must  be  valid. 

•  CHECK- WHILE-STATEMENT:  While  conditions  must  conform  to  the  same 
restrictions  as  if  conditions;  during  semantic  checking,  no  distinction  is  made 
between  if  and  while  conditions.  In  addition,  all  statements  within  the  while 
loop  must  be  valid. 

•  CHECK-IF-OPERAND-IN-SUBSYSTEM:  Controllers  (i.e.,  subsystem  update 
procedures)  may  access  only  those  components  (subordinate  subsystems  and 
primitive  objects)  which  are  part  of  the  subsystem  (that  is,  included  in  its 
controls  clause).  Currently,  the  application  specialist  indicates  which  compo¬ 
nents  are  part  of  the  subsystem  and  then  specifies  the  update  procedure  for  the 
subsystem.  This  semantic  check  is  actually  a  consistency  check  to  ensure  the 
controls  clause  and  update  procedure  are  compatible.  This  check  is  applied 
to  all  call  statements. 

—  Should  the  application  specialist  be  required  to  explicitly  specify  the  com¬ 
ponents  which  comprise  a  subsystem?  Doing  so  allows  the  above  described 
consistency  check  between  the  controllees  and  the  update  procedure  to  be 
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performed  as  a  “double  check”;  this  check  has  proved  helpful  during  testing 
to  keep  the  application  specification  “on-track.”  Or,  should  the  aggrega¬ 
tion  be  implicit  based  on  the  components  included  in  the  update  procedure? 
This  approach  would  make  it  tedious  to  check  which  components  comprise 
the  subsystem  and  does  not  allow  the  “double  check”  mentioned. 

•  CHECK-SETFUNCTION-STMT:  The  function  name  and  coefficients  specified 
in  a  setfunction  statement  must  be  valid.  That  is,  the  functionmame  must 
identify  an  existing  function  and  the  parameters  of  that  function  must  include 
a  primitive  object  of  the  same  type  as  the  object  specified  as  the  operand  of 
the  setfunction  statement.  Each  coefficient  specified  must  be  valid  for  the 
statement’s  operand. 

-  Should  the  application  specialist  be  required  to  specify  the  complete  func¬ 
tion  name  (which  may  be  quite  long  and  code-like,  especially  if  it  is  prefaced 
by  its  associated  object  class  type  as  Architect  requires)?  Or,  should  the 
application  specialist  be  required  to  identify  just  the  latter  portion  of  the 
name,  the  distinguishing  part?  Keep  in  mind,  the  entire  function  name  can 
be  generated  by  Architect  easily  by  prepending  the  object  class  of  the  state¬ 
ment’s  operand  to  this  distinguishing  name.  In  an  effort  to  keep  Architect 
very  domain-oriented  rather  than  programming-oriented,  we  have  opted  to 
take  the  latter  approach,  constructing  the  entire  function  name  given  just 
its  distinguishing  portion. 

•  CHECK-SETSTATE-STMT;  State  variables  and  their  new  values  specified  in  a 
setstate  statement  must  be  valid.  That  is,  the  variable  name  must  identify  an 
actual  attribute  of  a  primitive  object  of  the  same  type  as  the  object  specified  as 
the  operand  of  statement  and  the  new  value  must  be  of  the  same  data  type  as 
required  for  that  attribute.  Note:  a.s  with  the  function  names  in  setfunction 
statements  and  for  the  same  reason,  the  application  specialist  specifies  just  the 
distinguishing  part  of  each  attribute  name;  Architect  automatically  generates 
the  complete  name  by  prepending  the  object  class  name  to  this  distinguishing 
part. 
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3.  CHECK-FOR-EXPORTS-CORRESPONDING-TO-IMPORTS:  Input  data  required 
by  one  subsystem  must  be  produced  as  output  data  by  another  subsystem  within 
the  application.  If  no  subsystem  exports  data  which  can  serve  as  the  source  for  the 
input-data,  the  execution  simulation  can  not  be  processed  correctly. 

•  This  check  ensures  that,  for  each  import  item,  at  least  one  export  item  can 
be  found  that  produces  suitable  data,  i.e.,  that  some  subsystem  is  potentially 
capable  of  producing  the  needed  data.  It  can  not,  however,  assure  that  the  cor¬ 
rect  data  is  actually  available  when  needed  during  the  behavior  simulation.  For 
example,  assume  that  SUBSYSTEMl  produces  an  export  named  OUTPUTl  of 
category  TYPEl  and  SUBSYSTEM2  requires  an  import  named  DATAl  of  cate¬ 
gory  TYPEl.  If  SUBSYSTEM2  is  executed  before  SUBSYSTEMl,  OUTPUTl 
will  not  actually  be  available  when  needed.  Further,  using  the  above  example, 
even  if  SUBSYSTEMl  is  executed  before  SUBSYSTEM2,  there  is  no  guarantee 
that  a  valid  OUTPUTl  will  be  available  to  SUBSYSTEM2;  it  could  be  produced 
in  a  conditional  statement  whose  condition  is  not  met  during  execution. 

4.  CHECK- FOR-DUPES-IN-SUBSYSTEM:  Is  a  subsystem  component  listed  more  than 
once  in  the  controls  clause?  Such  a  duplication  may  actually  have  been  a  typograph¬ 
ical  error  and  not  what  the  application  specialist  intended.  A  warning  is  generated. 

5.  CHECK-FOR-UNUSED-COMPONENTS-IN-UPDATE:  Are  there  any  subsystems 
or  primitive  objects  listed  in  the  controls  clause  which  are  not  used  as  operands  in 
the  subsystem  update  procedure?  Such  an  omission  may  have  been  an  oversight 
and  other  statements  need  to  be  added  to  the  update  procedure.  Or,  the  subsys¬ 
tem/primitive  object  may  have  been  included  erroneously  in  the  controls  clause.  A 
warning  is  generated. 

5.3  Simulate  Execution 

After  the  proposed  application  specification  passes  all  semantic  checks,  it  is  fully 
specified  and  there  are  no  obvious  specification  errors  which  would  preclude  behavior  sim¬ 
ulation.  Ideally,  this  behavior  simulation  or  execution  demonstrates  to  the  application 
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specialist  that  the  application  he  has  specified  does,  indeed,  behave  as  intended.  If  the 
application  does  not  behave  as  intended,  the  application  specialist  may  edit  the  offend¬ 
ing  application  specification  to  “correct”  it  or  may  begin  again  with  another  complete 
application  definition. 


Figure  5.6.  Execute  Application 


Figure  5.6  presents  a  structure  chart  illustrating  the  behavior  simulation  process.  Ap¬ 
plication  execution  is  accomplished  by  invoking  EXECUTE-STATEMENT  for  each  state¬ 
ment  in  the  application  update  procedure.  Semantic  checks  have  already  verified  that  all 
the  statements  within  this  update  procedure  are  call  statements  (i.e.,  updates)  whose 
operands  are  subsystems  -  due  to  the  simplicity  of  the  currently  implemented  application 
executive,  if  and  while  statements  are  not  allowed  in  the  application  executive’s  update 
procedure. 

The  mission  of  a  subsystem  is  performed  by  EXECUTE-SUBSYSTEM,  which  calls 
EXECUTE-STATEMENT  for  each  statement  in  the  subsystem’s  update  procedure.  EXECUTE- 
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STATEMENT  performs  the  appropriate  action  for  the  type  of  statement  (e.g.  call,  if, 
while)  encountered. 

5.3.1  Call  statements  Call  statements  are  processed  by  DO-CALL-STATEMENT, 
which  performs  the  appropriate  function  based  on  the  type  of  call  requested. 

•  update  If  the  operand  of  the  update  is  a  subsystem,  EXECUTE-SUBSYSTEM  is 
called  to  perform  its  mission.  If  the  operand  of  the  statement  is  a  primitive  object,  the 
current  value  of  UPDATE-FUNCTION  is  retrieved  and  serves  as  the  first  parameter 
to  the  lisp  FUNCALL  function.  The  value  of  this  first  parameter  determines  which 
REFINE  function  is  to  be  invoked.  Thus,  FUNCALL  provides  a  mechanism  which 
allows  dynamic,  run-time  determination  of  the  function  to  be  called  and  allows  the 
behavior  simulation  code  to  remain  domain-independent. 

Figure  5.7  depicts  the  syntax  and  semantics  of  an  object  update  call.  The  syntax  for 
the  call  is  presented,  followed  by  a  sample  statement.  The  rectangle  represents  the 
statement’s  operand,  widgetl.  The  current  value  of  vidgetl’s  update-function  (in 
this  case,  widget-obj-updatel)  becomes  the  first  parameter  to  the  lisp  FUNCALL 
function;  its  succeeding  parameters  serve  as  parameters  to  the  function  invoked  by 
FUNCALL  (in  this  case,  widget-obj-updatel). 


update  <object-name> 

example:  update  widgetl 

widgetl 


update-function 


funcall(widget-obj-update1 , 
subsystemi,  widgetl) 


Figure  5.7.  Primitive  Object  Update  Execution 
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•  setfunction  The  update-function  of  the  statement’s  operand  is  replaced  by  the 
function  name  specified  in  the  statement.  In  addition  to  changing  the  value  in 
its  operand’s  UPDATE-FUNCTION,  the  setfunction  statement  also  provides  the 
means  to  change  the  current  value  of  any  or  all  of  its  operand’s  coefficients.  This  is 
pictured  in  Figure  5.8  which  shows  the  statement’s  syntax  and  a  sample  statement, 
as  well  as  the  effect  of  executing  that  sample  statement.  Because  one  of  our  goals  is  to 
make  application  specification  a  domain-oriented  rather  than  programmer-oriented 
process,  the  application  specialist  is  not  required  to  (in  fact,  should  not)  specify  the 
entire  update  function  name;  the  entire  name  is  constructed  by  prepending  the  name 
of  the  primitive  object’s  object  class  to  the  function  name  specified  by  the  appli¬ 
cation  specialist.  Note:  the  semantic  checks,  which  must  be  successfully  performed 
before  the  behavior  simulation  can  begin,  assure  that  the  specified  function  name 
and  coefficient /value  pairs  are  legal. 


setfunction  <object-name>  <new-update-function-name>  (coefficient-] ,  new-value-j)* 
example:  setfunction  widgetl  update2  (coeff,  15)  (coef2,  4.7) 


widget  1 


coefficients 

(ooef1 ,  40) 
(coef2,  1.9) 

update-function 

widget-obj-update1 

widgetl 


(coefi,  15) 
{coef2,  4.7) 


widget-obi-update2 


coefficients 


update-function 


Figure  5.8.  SetFunction  Execution 


e  setstate  Setstate  enables  the  application  specialist  to  directly  change  the  value  of 
any  of  its  operand’s  attributes  (unlike  the  OCU  model,  this  implementation  does 
not  make  a  distinction  between  “attributes,”  “state  data,”  and  “constants,”  all  of 
which  may  be  changed  via  setstate).  The  syntax,  a  sample  statement  and  the 
effect  of  executing  that  statement  are  depicted  in  Figure  5.9.  As  with  the  update 
function  name,  the  entire  attribute  name  is  automatically  generated  by  prepending 


5-21 


the  operand’s  object  class  to  the  attribute  names  specified  by  the  application  special¬ 
ist.  Again,  note:  the  semantic  checks,  which  must  be  successfully  performed  before 
behavior  simulation  can  begin,  assure  that  the  specified  attribute  names  and  their 
new  values  are  legal. 


setstate  <object-name>  (attribute-j,  new-value-|)* 
example:  setstate  widgetl  (a,  14)  (b,  5.5) 


attributes 


widgetl _  widgetl 


attributes 

widget-obj-a:  20 
widget-obj-b:  0.0 
widget-obj-c:  ’off 

widget-obj-a:  14 
widget-obj-b:  5.5 
widget-obj-c:  'off 

Figure  5.9.  SetState  Execution 


5.3.2  If  Statements  If  statements  are  executed  via  DO-IF-STMT.  If  the  IF-COND 
evaluates  to  true,  the  statements  following  the  then  are  executed.  If  the  IF-COND  eval¬ 
uates  to  false,  the  statements  following  the  else  are  executed  (or  the  statements  fol¬ 
lowing  the  end  if  if  no  else  is  specified).  The  condition  is  evaluated  via  EVALU ATE- 
BOOLEAN- EXPRESSION;  the  then  and  else  statements  are  executed  by  a  sequence  of 
calls  to  EXECUTE-STATEMENT. 

5.3.3  While  Statements  While  statements  are  executed  via  DO- WHILE- STMT. 
The  WHILE-COND  is  evaluated;  if  it  is  true,  the  statements  within  the  while  loop  are 
executed  via  calls  to  EXECUTE-STATEMENT  and  then  the  WHILE-COND  is  reevalu¬ 
ated.  Execution  continues  in  this  manner  until  the  WHILE-COND  evaluates  to  false,  at 
which  time  execution  proceeds  to  the  statement  following  the  end  while. 
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5-4  Summary 

This  chapter  presented  a  detailed  design  of  the  Preprocess,  Semantic  Checks,  and 
Execute  portions  of  Architect,  the  application  composition  system  which  was  implemented 
during  this  research  effort.  Where  relevant,  detailed  discussions  of  design  considerations 
and  implementation  alternatives  were  presented  to  explain  the  decisions  that  were  made. 


5-23 


VI.  Validation  Domain 


To  demonstrate  the  suitability  and  effectiveness  of  Architect,  the  application  com¬ 
position  system  described  in  the  previous  chapters,  one  must  select  a  domain,  conduct  a 
analysis  of  that  domain,  construct  an  appropriate  technology  for  it,  and  compose  useful 
applications  within  that  domain.  This  chapter  examines  the  domain  that  was  selected  for 
this  validation  process;  logic  circuits.  After  a  discussion  of  the  domain  analysis,  the  valida¬ 
tion  results  are  summarized  and  an  assessment  of  the  application  composer’s  performance 
is  presented. 

6.1  Background 

To  further  understand  the  OCU  software  architecture  model  and  its  implications. 
Architect  was  first  tested  using  a  pedagogical  domain  consisting  of  gadgets,  widgets,  things, 
contraptions  and  glibsnitzes.  This  nonsensical  domain  enabled  us  to  concentrate  on  the 
fundamentals  of  implementing  the  OCU  model,  free  of  the  built-in  biases,  constraints, 
and  limitations  inherent  in  a  “real”  domain.  This  freedom  allowed  experimentation  with 
various  implementation  strategies,  with  the  goal  of  developing  a  very  general  approach 
which  could  be  used  successfully  on  all  future  application  domains. 

Because  there  were  no  constraining  associations  between  the  domain’s  objects  and 
“real  world”  entities,  domain  modeling  was  trivial.  However,  an  effort  was  made  to  provide 
each  class  of  primitive  object  with  at  least  one  attribute/state  data,  covering  the  gamut  of 
REFINE  data  types  to  ensure  that  Architect  could  effectively  handle  each  one.  In  addition, 
object  update  functions  were  developed  to  be  fully  capable  of  exercising  all  aspects  of  the 
OCU  model. 

The  knowledge  and  experience  gained  through  experimentation  with  this  pedagogical 
domain  allowed  a  smooth  transition  into  the  official  validation  domain. 

6.2  Logic  Circuit  Domain 

A  subset  of  the  logic  circuit  domain  was  chosen  as  the  validating  domain  for  this 
application  composer.  It  is  well-known,  well- understood,  can  be  used  to  compose  a  wide 
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variety  of  practical  applications,  and  the  behavior  of  its  components  can  be  eaisily  described 
(an  important  consideration  given  the  limited  time  resources  available  for  this  research 
effort).  Refer  to  Appendix  A  for  a  standard  template  for  describing  a  primitive  object 
within  this  application  generation  system.  Appendix  E  contains  the  logic  circuit  domain 
modeled  in  the  REFINE  language. 

6.2.1  Domain  Analysis  -  Part  I 

6.2.1. 1  Identification  of  Primitive  Objects  The  first  step  of  the  domain  anal¬ 
ysis  was  to  determine  which  objects  should  be  included  in  the  validating  domain.  The 
following  were  obvious  choices  for  primitive  objects  within  the  domain: 

•  AND  gate 

•  OR  gate 

•  NAND  gate 

•  NOR  gate 

•  NOT  gate 

In  the  real  world,  none  of  the  above  objects  has  persistent  state  data  that  helps  to 
determine  the  result  of  its  next  update;  state  data  is  a  key  aspect  of  the  OCU  model 
from  which  we  developed  this  application  composition  system.  Although  the  following 
component  could  be  constructed  from  the  gates  identified  above,  it  was  included  as  a 
primitive  object  to  provide  an  example  of  state  data  manipulation. 

•  JK  FLIP-FLOP 

The  implemented  application  composer  uses  a  simplified  application  executive  which 
does  not  support  external  I/O.  Therefore,  all  data  used  in  the  application  must  be  gener¬ 
ated  within  the  application  and  any  data  produced  by  the  application  which  is  of  interest 
to  the  application  specialist  must  be  handled  within  the  application  itself.  To  accommo¬ 
date  these  temporary  restrictions,  the  following  objects  were  included  in  the  domain  to 
generate  data  and  display  it  to  the  application  specialist,  respectively: 
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•  SWITCH 


•  LED  (light  emitting  diode) 

6.2. 1.2  Identification  of  State,  Attribute  and  Constant  Data  Unlike  the  OCU 
model  upon  which  it  is  based,  this  implementation  makes  no  distinction  among  these 
categories  of  information  which  pertain  to  primitive  domain  objects.  All  of  these  data  are 
treated  in  the  same  manner  and  stored  as  REFINE  object  attributes. 

•  AND  gate,  OR  gate,  NAND  gate,  NOR  gate,  NOT  gate 

-  gate  delay;  integer 

-  manufacturer;  string 

-  meets  military  specifications?;  boolean 

-  power  required  by/ consumed  by  gate:  real 

•  JK  FLIP-FLOP 

-  gate  delay;  integer 

-  manufacturer:  string 

-  meets  military  specifications?:  boolean 

-  power  required  by/consumed  by  gate;  real 

-  set-up  delay:  integer 

-  hold  delay:  integer 

-  state:  boolean 

•  LED 

-  manufacturer:  string 

-  color  of  display:  symbol 

•  SWITCH 
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-  manufacturer:  string 

-  debounced?:  boolean 

-  gate  delay:  integer 

-  position  of  switch:  symbol  (on  or  olf) 

6. 2. 1.3  Identification  of  Object  Update  Functions  Under  the  OCU  model,  an 
object’s  behavior  is  encapsulated  in  its  update  function. 

•  AND  gate:  The  gate’s  output  is  the  result  of  the  boolean  AND  operation  on  its  two 
inputs. 

•  OR  gate:  The  gate’s  output  is  the  result  of  the  boolean  OR  operation  on  its  two 
inputs. 

•  NAND  gate:  The  gate’s  output  is  the  inverse  of  the  boolean  AND  operation  on  its 
two  inputs.  See  Table  6.1. 

Table  6.1.  Truth  Table  -  NAND  gate 


•  NOR  gate:  The  gate’s  output  is  the  inverse  of  the  boolean  OR  operation  on  its  two 
inputs.  See  Table  6.2. 

Table  6.2.  Truth  Table  -  NOR  gate 


•  NOT  gate:  The  gate’s  output  is  the  inverse  of  its  input. 
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•  JK  FLIP-FLOP:  If  there  is  no  clock  input  (i.e.,  it  is  false),  the  flipflop’s  state  does 
not  change.  If  there  is  a  clock  input,  the  flip-flop’s  state  may  change  depending  on 
the  inputs  and  its  current  state.  The  truth  table  for  a  JK  FLIP-FLOP  appears  in 
Table  6.3. 


Table  6.3.  Truth  Table  -  JK  FLIP-FLOP 


clock 

J 

K 

New  Q 

New  Q 

0 

X 

X 

old  Q 

~  {oldQ) 

1 

0 

0 

old  Q 

~  {oldQ)) 

1 

0 

1 

0 

1 

1 

1 

0 

1 

0 

1 

1 

1 

~  {oldQ) 

oldQ 

•  SWITCH;  If  the  switch  is  in  the  “on”  position,  its  output  is  true;  if  the  switch  is  in 
the  “off”  position,  its  output  is  false. 

•  LED:  The  LED  displays,  in  English,  the  value  of  its  input. 

6. 2.1. 4  Identification  of  Object  Input-Data  and  Output-Data  As  previously 
described,  under  the  OCU  model,  input-data  represents  external  data  required  by  an  object 
to  effect  its  update  properly;  output-data  represents  data  from  an  object’s  update  which 
must  be  made  available  to  other  objects  in  the  application.  With  the  identification  and 
description  of  the  update  functions  for  each  primitive  object,  this  data  is  now  obvious. 

•  AND  gate,  OR  gate,  NAND  gate,  NOR  gate: 

—  Input-data;  ini,  in2  =  signal  data  whose  primitive  data  type  is  boolean. 

-  Output-data:  outl  =  signal  data  whose  primitive  data  type  is  boolean. 

•  NOT  gate: 

—  Input-data;  ini  =  signal  data  whose  primitive  data  type  is  boolean. 

—  Output-data:  outl  =  signal  data  whose  primitive  data  type  is  boolean. 

•  JK  FLIP-FLOP: 

-  Input-data;  J,  K,  clock  =  signal  data  whose  primitive  data  type  is  boolean. 
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—  Output-data:  Q,  Q-bar  =  signal  data  whose  primitive  data  type  is  boolean. 


•  SWITCH: 

—  Input-data:  none. 

-  Output-data:  outl  =  signal  data  whose  primitive  data  type  is  boolean. 

•  LED 

—  Input-data;  ini  =  signal  data  whose  primitive  data  type  is  boolean. 

—  Output-data:  none. 

6.2.2  Domain  Analysis  -  Part  II  The  logic  circuit  domain,  as  defined  in  Sec¬ 
tion  6.2.1,  proved  to  be  inadequate  to  fully  demonstrate  all  aspects  of  the  application 
composer  implemented  during  this  research  effort.  Specifically,  each  primitive  object’s 
behavior  can  be  ftdly  specified  using  a  single  update  function;  Architect’s  capability  to 
dynamically  change  from  one  update  function  to  another  and,  thus,  to  change  an  object’s 
behavior  could  not  be  demonstrated  in  a  meaningful  way.  In  addition,  no  primitive  ob¬ 
jects  possessed  any  coefficient  data;  the  ability  to  change  the  effects  of  a  particular  update 
function  by  changing  the  value  of  one  or  more  coefficients  used  in  its  calculation  could  not 
be  shown.  This  shortcoming  in  the  logic  circuit  domain  was  overcome  by  adding  a  new 
primitive  object  (COUNTER)  and  by  adding  an  additional  update  function  for  the  LED 
object. 


6.2.2. 1  Identification  of  Primitive  Objects  The  following  primitive  object  was 
added  to  those  already  identified  in  Section  6.2.1. 1; 

•  COUNTER 

6. 2.2.2  Identification  of  State,  Attribute  and  Constant  Data  No  changes  were 
necessary  to  this  descriptive  information  previously  identified  in  Section  6. 2. 1.2.  For  the 
newly  identified  primitive  object: 

•  COUNTER 
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-  gate  delay:  integer 

-  manufacturer:  string 

-  meets  military  specifications?:  boolean 

-  power  required  by /consumed  by  gate:  real 

-  count  (state  data):  integer 

6. 2. 2.3  Identification  of  Object  Update  Functions  Except  for  LED,  aU  the 
update  functions  identified  in  Section  6.2.1.3  are  unchanged. 

•  LED: 

—  T-F-UPDATE:  If  the  input  is  true,  display  “true”  else  display  “false”. 

-  ON-OFF-UPDATE:  If  the  input  is  true,  display  “on”  else  display  “off”. 

•  COUNTER:  If  the  reset  input  is  true,  set  counter  to  0  else  if  the  clock  input  is  true, 
add  one  to  the  counter.  If  the  count  is  greater  than  the  maximum  value  for  the 
counter,  reset  counter  to  0.  The  maximum  value  for  the  counter  is  a  coefficient;  it 
can  be  dynamically  modified  during  behavior  simulation. 

6. 2.2.4  Identification  of  Object  Input-Data  and  Output-Data  All  input-data 
and  output-data  identified  in  Section  6.2. 1.4  remain  unchanged.  Input-data  and  output- 
data  for  the  new  primitive  object  follow: 

•  COUNTER: 

-  Input-data:  clock,  reset  =  signal  data  whose  primitive  data  type  is  boolean. 

-  Output-data:  Isb  (least  significant  bit),  msb  (most  significant  bit)  =  signal  data 
whose  primitive  data  type  is  boolean. 

6. 2. 2. 5  Identification  of  Coefficient  Data  Coefficients,  if  applicable  for  an  ob¬ 
ject,  are  used  in  calculating  its  new  state;  changing  a  coefficient  can  alter  the  object’s 
behavior  or  state  calculation.  The  following  coefficients  apply  to  this  domain: 
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•  COUNTER 


-  max-count:  Represents  the  maximum  value  to  which  the  counter  can  count. 
Because  the  counter’s  output  is  limited  to  two  bits  (to  simplify  the  connection 
process),  permissible  values  for  max-count  are  the  integers,  0-3.  The  default 
value  is  3. 

6.2.3  Domain  Analysis  -  Part  III  The  logic  circuit  domain  identified  and  described 
in  Sections  6.2.1  and  6.2.2  is  adequate  to  construct  any  desired  electronic  circuit;  its  prim¬ 
itive  objects  are  the  fundamental  building  blocks  of  all  real-world  circuits.  However,  com¬ 
posing  large  scale  circuits  from  these  very  primitive  components  is  tedious,  at  least  partially 
due  to  the  current  lack  of  an  effective  visual  interface.  Inclusion  of  “higher-level  primi¬ 
tives,”  objects  which  can  be  constructed  from  combinations  of  existing  primitive  objects 
but  are  treated  as  primitive  objects  within  the  framework  of  this  system,  can  simplify  this 
tedious  connection  process  for  larger  circuits.  Furthermore,  these  higher-level  primitives 
illustrate  an  important  concept:  what  constitutes  a  “primitive  object”  depends  on  the 
context  in  which  it  is  to  be  used. 

6.2.3. 1  Identification  of  New  Primitive  Objects  The  following  “higher-level” 
primitive  objects  were  added  to  the  logic  circuit  domain  to  simplify  the  connection  process 
for  large  circuits  as  well  as  to  illustrate  the  feasibility /utility  of  including  “higher-level 
primitives”  within  a  domain: 

•  DECODER  (3-to-8  Line) 

•  HALF  ADDER 

•  MULTIPLEXER  (4-Input  MUX) 

6. 2.3.2  Identification  of  State,  Attribute  and  Constant  Data 

•  DECODER 

-  delay:  integer 

-  manufacturer:  string 
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—  meets  military  specifications?:  boolean 

—  power  required  by/consumed  by  component:  real 


•  HALF  ADDER 

-  delay:  integer 

-  manufacturer:  string 

-  meets  military  specifications?:  boolean 

-  power  required  by /consumed  by  component:  real 

•  MULTIPLEXER 

-  delay:  integer 

-  manufacturer:  string 

-  meets  military  specifications?:  boolean 

-  power  required  by /consumed  by  component:  real 

€.2.3.3  Identification  of  New  Object  Update  Functions 

•  DECODER:  The  three  inputs,  taken  together,  represent  a  three-digit  binary  number. 
One  of  the  eight  output  lines  (numbered  0-7)  is  set  to  true  depending  on  the  value  of 
this  binary  number.  The  truth  table  for  a  3-to-8  line  decoder  appears  in  Table  6.4. 


•  HALF  ADDER:  The  two  inputs,  each  representing  a  single  binary  digit,  are  added 
together,  producing  the  sum  output.  The  second  output,  carry,  represents  the  carry¬ 
out  and  is  set  if  the  sum  can  not  be  represented  in  one  binary  digit.  The  truth  table 
for  a  half  adder  appears  in  Table  6.5. 


Table  6.5.  Tru 


h  Table  -  Half  Adder 


X 

Y 

Sum 

Carry 

0 

0 

0 

0 

0 

1 

1 

0 

1 

0 

1 

0 

1 

1 

0 

1 

•  MULTIPLEXER:  Two  of  the  inputs  (the  “select”  lines)  determine  which  one  of  the 
other  four  inputs  will  be  used  to  set  the  output.  The  function  table  for  a  4-input 
multiplexer  appears  in  Table  6.6. 


Table  6.6.  Truth  Table  -  4- Input  Multiplexer 


Si 

So 

Output 

0 

0 

lo 

0 

1 

h 

1 

0 

h 

1 

1 

h 

6.2.3. 4  Identification  of  New  Object  Input-Data  and  Output-Data 
m  DECODER: 

—  Input-data:  ini,  in2,  in3  =  signal  data  whose  primitive  data  type  is  boolean. 

-  Output-data:  mO,  ml,  m2,  m3,  m4,  m5,  m6,  m7  =  signal  data  whose  primitive 
data  type  is  boolean. 

•  HALF  ADDER: 

—  Input-data:  ini,  in2  =  signal  data  whose  primitive  data  type  is  boolean. 

-  Output-data:  s  (sum),  c  (carry)  =  signal  data  whose  primitive  data  type  is 
boolean. 
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•  MULTIPLEXER: 

—  Input-data:  inO,  ini,  in2,  in3,  sO,  si  =  signal  data  whose  primitive  data  type  is 
boolean. 

-  Output-data:  outl  =  signal  data  whose  primitive  data  type  is  boolean. 

6.3  Summary  of  Results  for  the  Logic  Domain 

Using  Architect,  several  electronic  circuits  were  constructed  from  the  primitive  ob¬ 
jects  of  the  logic  circuit  domain  and  their  behaviors  simulated.  In  all  cases,  when  the 
application  was  specified  and  composed  properly  (that  is,  all  import-export  connections 
were  correctly  made),  the  expected  results  were  achieved.  Table  6.7  lists  some  of  the 
circuits  tested  during  this  validation  phase  and  summarizes  certain  statistics  about  their 
compositions.  Examples  of  these  composed  circuits  are  contained  in  Appendix  C. 


Table  6.7.  Summary  of  Validation  Results 


Circuit 

Number  of  Primitives 

Number  of  Connections 

Decoder  from  low-level  primitives 

30 

43 

Decoder  from  high-level  primitive 

12 

11 

Full  Adder 

13 

16 

BCD  Adder 

43 

61 

Binary  Array  Multiplier 

14 

16 

Universal  Shift  Register 

25 

44 

6.4  Conclusions 

The  pedagogical  domain  of  widgets,  gadgets,  etc.  proved  extremely  useful  during 
initial  testing  of  the  system’s  application  composer.  Its  non-association  with  “real  world” 
entities  provided  a  freedom  to  fully  explore  the  mechanics  of  implementing  various  aspects 
of  the  OCU  (primarily  import/export  issues),  as  well  as  a  suitable  base  from  which  to 
test  the  system’s  manipulation  of  all  REFINE  primitive  data  types.  A  pattern  evolved  in 
creating  primitive  object  descriptions  which  became  the  standard  template  to  be  followed 
for  all  such  descriptions,  regardless  of  domain.  Its  nonsensical  nature;  further  underscored 
the  need  to  keep  the  application  composer  free  of  domain-specific  references. 
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The  application  composer  performed  very  well  when  the  the  pedagogical  domain  was 
replaced  by  the  logic  circuit  domain.  The  semantic  analysis  and  behavior  simulation  pro¬ 
cesses  required  no  modifications.  However,  with  the  advent  of  a  real  domain,  shortcomings 
were  identified  with  the  import /export  process.  Originally,  imports  were  associated  with 
their  corresponding  exports  by  matching  data  names  only.  In  a  pedagogical  domain  that 
could  be  constructed  in  any  manner  to  suit  the  circumstances,  this  was  no  disadvantage. 
With  a  real  domain,  this  scheme  for  matching  imports  to  exports  was  quickly  exposed  as 
inadequate  and  overly  restrictive.  Import/export  names  were  retained  for  internal  refer¬ 
ence  only  and  an  import/export  data  category  was  added.  The  data  category,  described 
in  Section  5.1.3,  serves  as  the  discriminator  for  determining  potential  import /export  con¬ 
nections;  this  is  its  sole  function.  This  system  modification,  though  made  in  response  to 
the  logic  circuit  domain,  is  clearly  an  improvement  which  will  likely  satisfy  most  other 
application  domains. 

Proper  analysis  of  any  potential  domain  is  essential  to  maintaining  the  application 
composer’s  domain  independence.  The  composer  must  be  free  of  inappropriate,  domain- 
specific  adaptations  which  would  further  complicate  software  maintenance  and  limit  Ar¬ 
chitect’s  usefulness  and  flexibility.  Diflficulties  in  modeling  the  domain  must  be  carefully 
evaluated  before  modifications  to  the  composer  are  considered  to  accommodate  pecularities 
of  the  domain;  can  the  domain  be  described  in  different  manner  to  overcome  this  apparent 
problem?  is  the  proposed  modification  applicable  to  other  domains?  During  logic  circuit 
domain  analysis,  for  example,  various  aspects  of  the  domain  appeared  to  be  difficult  to 
model.  In  most  cases,  an  alternative  modeling  approach  was  found  to  represent  the  infor¬ 
mation  within  the  context  of  the  existing  composition  system.  In  one  case  mentioned  in 
the  previous  paragraph,  the  proposed  modification  was  deemed  to  be  appropriate  for  most 
other  domains  as  well;  the  change  was  incorporated  into  Architect. 

Architect  is  a  domain-independent  system.  Its  straightforward  design  easily  accom¬ 
modated  its  extension  into  the  logic  circuit  domain.  Rigorous  adherence  to  the  paradigm 
established  by  the  primitive  object  template  discussed  in  Appendix  A  results  in  primitive 
objects  which  fit  properly  into  Architect’s  framework.  This  is  a  flexible  system  which 
appears  to  be  capable  of  being  used  for  a  wide  variety  of  application  domains. 
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VII.  Conclusions  and  Recommendations 


This  chapter  provides  a  summary  of  the  accomplishments  of  this  thesis  effort.  It  also 
discusses  the  conclusions  which  can  be  drawn  from  this  work  and  presents  some  recom¬ 
mendations  for  further  research. 

7. 1  Summary  of  Accomplishments 

The  objective  of  this  research  was  stated  in  Chapter  I: 


Develop  a  formalized  model  of  a  software  architecture  and  implement  it  within 
a  domain-specific  application  composition  system. 

To  that  end,  the  current  literature  on  software  architectures  was  examined  and  various 
architectures  evaluated  in  an  attempt  to  find  an  existing  one  suitable  for  composing  appli¬ 
cations  within  our  system.  One  such  architecture,  the  Object-Connection-Update  model 
which  was  developed  by  the  Software  Engineering  Institute,  was  studied  at  length  and  was 
ultimately  selected: 

•  It  had  been  used  successfully  to  design  and  implement  various  other  projects  at  the 
SEI  and  AFIT  (23,  7,  40) 

•  It  was  described,  in  considerable  detail,  in  several  publications  (23,  24,  42) 

•  It  was  capable  of  supporting  our  application  composition  system. 

The  OCU  model  was  formalized  using  the  REFINE  wide-spectrum  language  into  a  formally 
specified,  executable  prototype.  This  prototype  of  the  application  composer  was  validated 
using  the  logic  circuit  domain. 

7.2  Conclusions 

The  following  general  conclusions  can  be  drawn  from  this  research: 
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1.  Application  composition  systems,  such  as  that  described  in  Chapter  III,  are  feasible. 
This  was  clearly  demonstrated  in  Appendix  C,  where  several  complex  logic  circuits 
were  constructed  using  Architect. 

2.  Non-programmers,  who  are  very  knowledgeable  about  a  particular  domain,  can  create 
quite  sophisticated  applications  without  the  direct  assistance  of  software  profession¬ 
als.  These  application  specialists,  armed  only  with  detailed  knowledge  about  their 
own  domains  and  an  application  composition  system  with  an  appropriately  mod¬ 
eled  domain-specific  technology  base,  can  quickly  construct  effective  (they  behave  as 
intended)  applications  to  satisfy  virtually  any  requirement  within  the  domain. 

3.  A  suitable  software  architecture  is  an  essential  ingredient  of  a  flexible,  domain- 
independent  application  composition  system.  The  software  architecture  allows  the 
system/application  designer  to  concentrate  on  the  fundamental  elements  of  construct¬ 
ing  a  system/ application;  what  components  must  be  included  and  what  connections 
are  appropriate  among  those  components.  How  those  connections  are  actually  made 
is  the  software  architecture’s  concern.  This  separation  of  concerns  allows  the  focus 
to  be  on  what  should  be  constructed,  not  how  it  is  to  be  implemented;  we  can  expect 
such  a  focus  to  produce  better  designed,  more  reliable  systems. 

The  following  specific  conclusions  can  be  drawn  about  Architect,  the  application 
composition  system  which  was  developed  during  this  thesis  effort: 

1.  Architect  works.  A  wide  range  of  electronic  circuits  were  constructed  during  testing, 
some  of  which  are  presented  in  Appendix  C. 

2.  Architect  is  readily  extensible.  Initially,  to  demonstrate  the  feasibility  of  the  sys¬ 
tem  concept  and  to  evaluate  various  implementation  strategies  (primarily  for  im¬ 
port/export  areas),  a  pedigogical  domain  was  used.  It  was  a  simple  matter  to  re¬ 
orient  the  system  to  the  logic  circuit  domain,  an  effort  which  required  only  three 
manhours  (the  time  needed  to  created  a  new  domain-specific  language  and  technol¬ 
ogy  base).  Changing  domains  required  no  modifications  to  the  composition  system 
source  code;  only  the  domain-specific  technology  base  (and  DSL)  required  changes. 
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The  template  in  Appendix  A  should  be  helpful  to  software  engineers  who  must  main¬ 
tain  the  technology  base. 

3.  Domain  analysis  is  critical.  An  application  composition  system  provides  only  the 
framework  around  which  domain  applications  can  be  constructed;  the  technology 
base  supplies  the  details.  The  contents  of  the  technology  base  depend  directly  upon 
the  results  of  a  domain  analysis.  An  ideal  domain  analysis  will  identify  all  the  ap¬ 
propriate  objects  within  the  domain  and  wiU  describe  them  properly  (attributes, 
input-data,  output-data,  update  functions,  etc.);  virtually  any  meaningful  applica¬ 
tion  within  the  domain  can  be  constructed  when  all  the  necessary  objects  are  prop¬ 
erly  identified.  A  typical  domain  analysis  will  omit  some  necessary  domain  objects 
and/or  improperly  describe  them;  applications  can  not  be  composed  correctly  if  the 
necessary  components  are  not  available  and  can  not  behave  as  required  if  the  compo¬ 
nents  are  incorrectly  defined.  The  good  news:  because  Architect  is  easily  extensible, 
oversights  and  incorrectly  defined  objects  can  be  quickly  fixed  once  identified. 

4.  Software  engineers  who  work  with  Architect  must  clearly  understand  the  OCU  model 
and  its  implementation.  A  domain  analysis  may  identify  a  situation  which  apparently 
can  not  be  accommodated  by  the  OCU  model.  For  example,  if  a  primitive  object 
has  two  update  functions,  each  of  which  performs  a  different  operation  with  different 
input-data  and  output-data  (a  situation  which  can  not  be  handled  by  the  model), 
an  unwary  software  engineer  might  be  tempted  to  change  the  implementation  to 
ax:commodate  it. 

5.  Making  connections  between  import  items  and  the  export  items  that  are  to  provide 
their  data  requests  can  be  very  tedious  in  some  domains  using  the  current  system; 
a  glance  at  some  of  the  application  specifications  in  Appendix  C  clearly  illustrates 
this  point.  The  visual  system  will  alleviate  this  problem.  However,  even  without  the 
visual  system,  meaningful,  complex  applications  can  be  constructed;  it  just  takes  a 
bit  of  time  and  effort. 

6.  The  use  of  the  Software  Refinery  environment,  with  its  integrated  language  definition 
facility  (DIALECT),  graphical  user  interface  (INTERVISTA),  and  programming  lan¬ 
guage  (REFINE)  which  incorporates  many  built-in  object  manipulation  functions. 
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greatly  simplified  and  expedited  the  implementation  of  Architect.  With  DIALECT, 
parsers  for  domain-specific  and  architecture  languages  were  easily  generated  from 
simple  BNF  descriptions  of  the  languages.  Output  from  these  DIALECT-generated 
parsers  was  automatically  converted  into  an  abstract  syntax  tree  format  and  stored 
in  the  structured  object  base.  The  REFINE  language’s  built-in  functions  provide  an 
easy  way  to  manipulate  the  object  base  and  its  standard  programming  language  con¬ 
structs  supply  the  functionality  expected  of  any  high-level  programming  language;  in 
fact,  its  direct  support  of  set  theory  and  set-based  operations  provides  more  power 
than  can  be  achieved  with  most  commonly  used  languages.  The  availability  of  these 
powerful,  well-integrated  tools  eliminated  the  need  to  write  comparable  tools;  this 
significantly  shortened  the  development  process. 

7.5  Recommendations  for  Further  Research 

The  following  issues  should  be  addressed  in  future  reseach  efforts: 

1.  Code  generation  -  The  application  composition  system  described  in  Chapter  III 
includes  a  formal  specification  generation  capability  which  is  intended  to  feed  an 
automatic  code  generator.  Currently,  the  behaviors  of  application  specifications, 
which  are  created  by  application  specialists,  can  be  simulated  to  verify  that  behavior. 
However,  this  is  merely  a  simulation  and  is  neither  robust  nor  efficient  enough  to 
support  a  production  system. 

2.  Extending  Domains  -  Architect,  as  currently  implemented,  does  not  provide  any  au¬ 
tomated  support  for  extending  the  domain  knowledge  which  resides  in  the  domain 
model.  Extensions  to  the  dommn  model  must  be  made  manually  and  are  limited 
by  the  knowledge  and  understanding  of  the  domain  engineer.  The  Kestrel  Interac¬ 
tive  Development  System  (KIDS)  should  be  studied  to  ascertain  its  ability  to  allow 
automated  extensions  to  Architect’s  domain  models. 

3.  Application  executive  -  Only  a  very  simple  application  executive  was  considered  in 
this  implementation.  This  “application  executive”  was  merely  a  specialized,  highest 
level  subsystem.  Obviously,  such  a  simple  approach  is  inadequate  for  most  mean- 
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ingful,  production  domains.  What  should  be  the  role  of  an  executive?  How  does 
the  executive  interface  with  the  environment  to  obtain  the  necessary  external  data? 
Can  the  executive  perform  in  a  real-time  environment  with  concurrency  and  time 
constraints?  These  questions  must  be  answered  before  a  full-scale,  production  appli¬ 
cation  composition  system  can  be  developed. 

4.  Additional  validating  domains  -  We  have  demonstrated  that  an  application  composi¬ 
tion  system  is  feasible.  However,  application  compositions  need  to  be  attempted  in  a 
wider  variety  of  real-world  domains  to  further  assess  its  strengths  and  shortcomings. 
One  domain  to  consider  for  such  further  evaluation  is  the  simulation  domain  for  the 
Joint  Modeling  and  Simulation  System  (J-MASS). 

5.  Alternatives  to  the  OCU  model  -  The  complete  OCU  model  as  described  in  (24) 
has  not  been  implemented.  Certain  changes  (for  example,  the  omission  of  several 
subsystem  and  object  procedural  interfaces)  were  made  to  the  model  to  accommodate 
the  time  limitation  of  this  research  effort  and  to  conform  with  certain  predetermined 
requirements  (e.g.,  that  all  objects  would  be  created  during  the  specification,  not 
dynamically  at  run-time).  Other  changes  should  also  be  considered.  For  example, 

•  the  model  does  not  currently  allow  a  subsystem  to  directly  query  a  subordinate 
object  concerning  its  state  data;  this  would  seem  to  be  a  desirable  feature, 
especially  when  dealing  with  if  and  while  statement  conditions. 

•  there  is  currently  no  way  to  “hide”  exports  inside  a  subsystem  (that  is,  to 
prevent  them  from  being  used  outside  the  subsystem;  all  exports  are  treated 
alike  and  may  be  used  for  the  source  of  any  compatible  import.  Within  the 
validating  domain,  there  were  many  instances  where  “intermediate”  outputs 
were  produced  and  consumed  within  a  single  subsystem;  there  was  never  any 
intention  to  use  these  “intermediate”  results  in  any  other  subsystem.  In  fact, 
using  such  “intermediate”  results  would  likely  produce  an  incorrect  composition. 
But,  in  keeping  to  the  OCU  model,  all  exports  are  globally  accessable. 

The  OCU  model  must  be  carefully  studied  within  the  context  of  this  application 
composition  system  and  its  suitability  further  evaluated.  Additional  tests  may  dis- 
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cover  that  it  is  too  restrictive  (or  permissive)  to  allow  appropriate  compositions  for 
all  domains  of  interest. 


Final  Comments 

The  application  composition  system  developed  during  this  thesis  effort  is  a  signif¬ 
icant  first  step  in  a  software  development  revolution.  Software  engineers  will  no  longer 
develop  systems  to  satisfy  a  single,  unique  requirement  (complicated  though  it  may  be); 
end  users  wiU  create  their  own  applications,  without  intervention  by  computer  profession¬ 
als.  Long  waits  for  inadequate,  often  unreliable  and  incorrect  software  products  will  be 
only  a  distant  memory.  Software  maintenance,  once  the  major  expense  in  any  software 
system’s  lifecycle,  will  be  an  issue  no  longer;  application  specifications,  not  source  code, 
will  be  maintained  by  the  end  users  themselves.  Software  development  teams  will  be 
composed  of  domain  engineers,  software  engineers,  and  application  specialists;  knowledge 
about  domains  must  be  formalized,  application  composition  and  generation  systems  must 
be  developed/maintained,  and  problems  within  a  domain  must  be  analyzed,  evaluated  and 
solved. 
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Appendix  A.  Requirements  for  Specifying  Primitive  Objects 


Architect,  which  was  implemented  in  this  research  effort,  is  predicated  on  the  as¬ 
sumption  that  all  primitive  objects  are  defined  in  a  precise,  standardized  manner  by  the 
software  engineer.  This  appendix  provides  a  template  to  be  used  by  the  software  engineer 
when  creating  a  definition  for  all  primitive  object  classes  within  any  domain  and  explains 
the  significance  of  the  mandatory  items. 


INPUT- DATA 

{(name,  category,  type-data,  ,)...} 

OUTPUT-  DATA 

{(name,  category,  type-data,  ,)...} 

COEFFICIENTS 

{(name,  value) ... } 

UPDATE-  FUNCTION 

function-name 

Attributes,  Current-State,  Constants 

variable-i 

variable2 

variable^, 

Figure  A.l.  Standard  Primitive  Object  Definition 


A.l  Primitive  Object  Definition  Template 

Figure  A.l  illustrates  the  standard  template  for  all  primitive  object  definitions.  It  is 
based  on  the  kinds  of  data  available  to  primitive  objects  as  described  by  the  OCU  model. 
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See  Appendix  E  for  examples  of  primitive  object  definitions  from  the  logic  circuit  domain 
used  to  validate  this  implementation. 

A. 1.1  INPUT-DATA  INPUT-DATA  describes  the  data  which  is  external  to  the 
object  but  is  needed  to  update  it.  INPUT-DATA  is  implemented  as  a  set  of  IMPORT- 
OBJ  objects;  during  preprocessing  (BUILD-IMPORT-EXPORT-AREA),  each  entry  in  the 
set  becomes  a  part  of  the  import  area  of  the  subsystem  which  “controls”  that  primitive 
object. 

•  IMPORT-NAME:  identifies  the  name  by  which  this  piece  of  data  will  be  referred.  In 
the  object’s  update  function,  this  name  must  appear  in  a  GET-IMPORT  function 
call  to  obtain  the  data’s  actual  value.  Additionally,  the  name  will  be  displayed 
to  the  application  specialist  during  preprocessing  (BUILD-IMPORT-SOURCES)  to 
uniquely  identify  this  input-data  item  when  more  than  one  piece  of  external  data  can 
serve  as  its  source. 

•  IMPORT-CATEGORY:  identifies  the  type  of  the  external  data  required,  in  domain- 
oriented  terms.  For  example,  one  might  specify  that  the  data  must  be  of  the  category 
“temperature”  or  “time,”  rather  than  merely  a  real  number  or  an  integer.  This  is 
analogous  to  the  Ada  programming  language  which  encourages  the  use  of  subtypes 
to  further  constrain  the  possible  values  which  a  given  variable  can  accept.  Only 
EXPORT-OBJs  with  the  same  category  can  be  considered  as  potential  sources  for 
this  input-data  item. 

•  IMPORT-TYPE-DATA:  identifies  the  primitive  data  type  of  the  required  data.  This 
data  type  is  used  only  for  checking  and  evaluating  the  expressions  in  if  and  while 
statements.  The  current  implementation  accommodates  only  primitive  data  types 
(integer,  real,  boolean,  string  and  symbol). 

A. 1.2  OUTPUT-DATA  OUTPUT-DATA  describes  the  data  which  the  object  must 
make  available  externally  to  other  application  components.  It  is  implemented  as  a  set  of 
EXPORT-OBJ  objects;  during  preprocessing  (BUILD-IMPORT-EXPORT- AREA),  each 
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entry  in  the  set  becomes  a  part  of  the  export  area  of  the  subsystem  which  “controls”  that 
primitive  object. 


•  EXPORT-NAME:  identifies  the  name  by  which  this  piece  of  data  will  be  referred.  In 
the  object’s  update  function,  this  name  must  appear  in  a  SET-EXPORT  function  call 
to  make  the  new  value  accessible  to  other  application  components.  Additionally,  the 
name  will  be  displayed  to  the  application  specialist  during  preprocessing  (BUILD- 
IMPORT-SOURCES)  to  uniquely  identify  this  output-data  as  a  possible  source  when 
more  than  EXPORT-OBJ  can  serve  as  the  source  for  an  IMPORT-OBJ. 

•  EXPORT-CATEGORY:  identifies  the  type  of  the  external  data  (OUTPUT-DATA) 
produced,  in  domain-oriented  terms.  OUTPUT-DATA  can  be  used  only  by  those 
import  items  which  have  the  same  category. 

•  EXPORT-TYPE-DATA:  identifies  the  primitive  data  type  of  the  required  data.  This 
data  type  is  used  only  for  checking  and  evaluating  the  expressions  in  if  and  vhile 
statements.  The  current  implementation  accommodates  only  primitive  data  types 
(integer,  real,  boolean,  string  and  symbol). 

A. 1.3  COEFFICIENTS  In  the  OCU  model,  coefficients  represent  data  which  can 
be  used  in  an  object’s  update  function  to  alter  the  behavior  or  performance  of  the  object. 
In  this  implementation,  coefficients  are  expected  to  have  a  default  value,  determined  by 
the  domain  analysis,  and  can  be  modified,  as  necessary,  at  any  point  in  the  execution  via 
a  setfunction  statement  in  the  subsystem’s  update  procedure. 

A  coefficient  is  represented  as  a  NAME-VALUE-OBJ:  NAME- VALUE-NAME  is  the 
name  of  the  coefficient  (to  be  used  in  the  update  function  when  referencing  this  coefficient) 
and  NAME- VALUE- VALUE  is  the  current  value  associated  with  the  coefficient.  The 
coefficient’s  value  is  not  constrained  by  a  particular  data  type;  rather,  it  is  implemented  as 
a  REFINE  ANY-TYPE  which,  as  its  name  implies,  allows  any  type  of  data  to  be  stored. 
This  requires  that  the  software  engineer  ensure  compatibility  of  data  types  between  default 
coefficient  values  and  their  usage  in  object  update  functions.  In  addition,  it  imposes  a 
responsibility  on  the  application  specialist  to  provide  compatible  data  when  specifying 
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new  values  for  coefficients  in  setf  unction  statements;  no  semantic  checks  can  ensure  data 
consistency  before  behavior  simulation.  This  may  appear  to  unduly  burden  the  application 
specialist;  however,  this  approach  provides  the  flexibility  needed  to  accommodate  any 
potential  domain’s  requirements  for  number  and  type  of  coefficients. 

A. 1.4  UPDATE-FUNCTION  This  variable  stores  the  name  of  the  function  cur¬ 
rently  used  to  update  the  primitive  object.  During  behavior  simulation,  when  an  update 
statement  for  a  primitive  object  is  encountered.  Architect  retrieves  the  name  of  the  func¬ 
tion  to  be  used  for  updating  from  this  variable  and  calls  the  indicated  function  to  complete 
the  operation.  It  is  expected  that  domain  analysis  will  have  identified  a  “normal”  or  de¬ 
fault  update  function  for  each  primitive  object  class.  An  alternate  update  function  can 
be  specified  at  any  time  during  behavior  simulation  via  a  setf  unction  statement  in  the 
subsystem’s  update  procedure;  subsequent  update  statements  applied  to  that  object  will 
use  this  new  update  function. 

A.  1.5  Attributes,  CurrenLState,  Constants  Although  the  OCU  model  considers 
these  to  be  different  kinds  of  data,  this  implementation  makes  no  such  distinctions;  all 
are  modeled  as  REFINE  attributes  of  a  primitive  object.  A  strict  interpretation  of  the 
OCU  model  would  allow  only  current ^tate  data  to  be  modified  directly  by  a  setstate 
statement;  the  current  implementation  allows  any  of  this  data  to  be  changed.  If  it  becomes 
necessary  or  desirable  to  do  so,  enforcing  these  distinctions  could  be  accomplished  via  a 
naming  convention  scheme;  as  an  example,  attributes  (object  characteristics)  could  be 
represented  with  the  letters  “ATTR”  imbedded  within  attribute  names,  “STATE”  within 
currentjstate  names  and  “CONST”  within  the  names  of  constants. 

A.  1.6  Miscellaneous 

•  AU  primitive  object  definitions  must  begin  with  an  object  class  specification.  This 
implementation  assumes  that  each  primitive  object  class  name  consists  of  the  kind 
of  real-world  object  represented  by  the  class  followed  by  “-OBJ”  (e.g.  AND-GATE- 
OBJ).  This  class  name  (minus  the  “-OBJ”)  appears  in  the  domain-specific  grammar 


when  specifying  (i.e.,  creating)  the  object  instances  which  are  to  be  part  of  the 
application. 

•  All  variable  names  associated  with  an  object  are  prefaced  by  the  complete  object 
class  name.  This  ensures  that  variable  names  are  unique  -  the  software  engineer 
can  use  descriptive,  domain-oriented  names  for  all  variables  without  being  concerned 
that  some  other  class  of  primitive  object  might  already  have  a  variable  with  the 
same  name.  It  also  allows  the  application  specialist  to  refer  to  variables  in  setstate 
statements  by  just  this  domain-oriented  name;  Architect  can  assemble  the  entire 
variable  name  by  prefacing  the  given  name  with  the  object  class  of  the  statement’s 
operand. 

•  All  update  functions  are  included  in  the  primitive  object  definition.  Each  update 
function  is  coded  as  a  REFINE  function  whose  parameters  include  the  subsystem 
which  controls  the  primitive  object  being  updated  and  the  primitive  object  itself. 
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Appendix  B.  Guide  to  Using  the  Application  Composer 


Maintaining  a  computer  program,  especially  one  written  by  a  colleague  who  is  no 
longer  available  for  consultation,  can  be  a  daunting  task.  This  appendix  attempts  to  ease 
that  burden  somewhat  by  providing  detailed,  technical  information  needed  to  execute  the 
application  composer.  The  intended  users  of  this  guide  are  the  software  engineers  who  will 
be  tasked  to  extend  the  capabilities  of  this  composer.  It  is  not  written  for  the  software 
engineers  who  create  and  maintain  domain-specific  languages  and  technology  bases;  helpful 
information  of  this  nature  can  be  found  in  Appendix  B  of  (33). 

B.l  Getting  Started 

The  application  composer  must  execute  within  the  Software  Refinery  environment 
which  must  be  accessed  through  an  Emacs  process.  To  enter  the  Software  Refinery  Envi¬ 
ronment: 

1.  From  a  command  or  shell  window,  set  the  current  directory  to  that  which  contains 

Architect. 

2.  Invoke  Emacs  (emacs  or  emacsft  to  run  in  the  background). 

After  the  large  Emacs  window  appears,  start  Software  Refinery  by  pressing  <esc>  (which 
causes  the  cursor  to  jump  to  the  lower  left  corner  of  the  Emacs  window)  and  typing 
run-refine.  After  a  short  initialize  phase  during  which  various  messages  wiU  be  displayed 
on  the  right  side  of  the  Emacs  window.  Software  Refinery  wiU  be  ready  for  use. 

The  application  composer’s  executable  code  modules  (suffixed  by  .fasl  must  be 
loaded  before  Architect  can  be  executed;  if  no  executable  modules  exist,  they  must  be 
created  via  a  compile  step.  There  are  many  dependencies  among  the  many  files  which 
comprise  Architect.  Therefore,  to  ensure  all  files  are  compiled  and/or  loaded  in  the  proper 
order,  it  is  recommended  that  a  “load”  file  (to  load  all  executable  modules)  and  a  “compile- 
and-load”  file  (to  compile  source  code  modules  and  load  the  newly  created  executable 
modules)  be  used.  The  “compile-  and-load”  file  for  Architect  is  listed  in  Section  B.3. 
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A  “compile-and-load”  file  is  actually  a  lisp  function  whose  name  follows  defun  (this 
discussion  also  applies  to  “load”  files).  This  function  must  be  loaded  into  the  Refine 
object  base  before  it  can  be  executed.  This  is  accomplished  by  typing  (load  "cl")  at 
the  Refine  prompt  (•>),  where  cl  corresponds  to  the  name  of  the  lisp  function.  After  the 
function  is  loaded,  it  can  be  executed  by  typing  (cl).  Execution  of  the  function  causes 
each  designated  file  to  be  compiled  and  loaded,  in  turn.  Note:  the  DIALECT  system  must 
be  loaded  first  ((load-system  "dialect"  "1-0")). 

B.2  Using  the  Application  Composition  System 

Now  that  Architect  is  loaded,  it  is  ready  for  use.  If  the  user  wants  to  employ  the  full 
capabilities  of  the  composition  system,  he  should  refer  to  the  instructions  in  Appendix  A 
of  (33). 

However,  if  the  user’s  focus  is  strictly  the  application  composer  itself  (i.e.,  he  is  not 
interested  in  using  generic  components,  loading  previously  saved  components/architectural 
fragments,  nor  editing  application  definitions),  the  easiest  and  fastest  method  of  populating 
the  structured  object  base  is  via  parsing.  This  is  accomplished  using  the  left  side  of  the 
Emacs  window.  First,  establish  it  as  the  “active”  window  by  moving  the  cursor  there 
and  clicking  the  right  mouse  button.  Then  type  as  desired  using  the  Emacs  editor.  Or, 
textual  application  definitions  may  be  loaded  from  any  file  by  typing  <ctrl>  x  <ctrl>  f , 
and  completing  the  file  pathname  that  appears  at  the  bottom  of  the  window.  When  the 
desired  application  definition  appears  in  the  left  window,  parse  it  into  the  Refine  object 
base  as  follows: 

1.  Move  the  cursor  to  the  beginning  of  the  definition  and  type  <esc><8pace>  to  mark 
the  beginning  of  the  parse  block. 

2.  Move  the  cursor  just  beyond  the  end  of  the  definition  and  type  esc><space>  to  mark 
the  end  of  the  block. 

3.  Move  the  cursor  back  to  the  top  of  the  block  and  <e8c>  w  to  move  the  block  into 
the  Emacs  buffer. 

4.  Move  the  cursor  to  the  right  side  of  the  Emacs  window,  establish  it  as  the  “active” 
window,  and  type  at  the  Refine  prompt: 
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(\#>  <ctrl>y  <ctrl>  ) 

Note;  <ctrl>  y  causes  the  contents  of  the  Emacs  buffer  to  be  “dumped”  into  a  the 
Refine  parse  command  (#>). 

Upon  successful  completion  of  the  parse  command,  the  application  definition  is  stored 
as  an  abstract  syntax  tree  (AST)  in  the  Refine  object  base.  The  root  of  that  AST  is  now 
the  “current  node;”  this  is  significant  as  Refine  rules  operate  only  on  the  current  node. 
In  the  present  implementation,  the  user  interacts  with  Architect  by  invoking  applicable 
rules.  The  list  of  currently  applicable  rules  can  be  obtained  by  typing  (rs)  (“rule  search”). 
After  deciding  what  he  wants  Architect  to  do,  the  user  applies  the  chosen  rule  by  typing 
(eu:  n)  where  n  is  the  number  of  the  appropriate  rule.  The  user  is  prompted  through  any 
interactions  which  result  from  applying  that  rule. 

If  the  user  is  interested  only  in  the  preprocess,  semantic-check,  and  execute  system 
components,  a  simplified  the  application  composer  can  be  used.  The  required  models  for 
the  simplified  version  are  listed  in  their  compilation  order  in  Figure  B.l.  It  should  be  noted 
that  the  user  never  loses  the  ability  to  “edit,”  “load,”  and  “store”  application  definitions, 
even  with  this  simplified  system.  Because  all  objects  must  have  unique  names,  reparsing 
a  modified  copy  of  the  original  application  has  the  effect  of  “editing”  the  application.  We 
have  already  seen  how  application  definitions  can  be  “loaded”  from  a  text  file;  application 
definitions  can  be  “saved”  into  a  text  file  via  the  Emacs  command,  <ctrl>  x  <ctrl>  s. 

B.3  “Compile- And- Load”  File  for  the  Application  Composition  System 

Including  the  following  “compile-and-load”  file  into  this  user’s  guide  accomplishes 
two  objectives: 

1.  It  lists  the  files  which  are  required  to  execute  Architect  within  the  logic  circuit  do¬ 
main. 

2.  It  establishes  a  compilation  order  to  accommodate  program  dependencies. 

Nbeginfsinglespace} 

(defun  cl() 
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dialect 

lisp-read. lisp 

dm-ocu 

gram-ocu 

set-debug 

globals 

import s -export s 

eval-expr 

execute 

domain-specific 
technology  base 
files 

« 

semantic-checks 

gram-dsl 

Figure  B.l.  Compilation  Order  for  Simplified  Application  Composer  System 


(load-system  "dialect"  "1-0") 


(compile-file  " ./OCU-dm/dm-ocu") 

(load  " . /OCU-dm/dm-ocu" ) 

(compile-file  " . /OCU-dm/gram-ocu") 

(load  " . /OCU-dm/gram-ocu" ) 

(compile-file  "./DSL/globals") 

(load  "./DSL/globals") 

(compile-file  " ./DSL/lisp-utilities. lisp") 
(load  " , /DSL/lisp-utilities .lisp") 

(compile-file  " ./DSL/obj-utilities") 

(load  "./DSL/obj-utilities") 

(compile-file  " ./DSL/read-utilities") 
(load  "./DSL/read-utilities") 

(compile-file  "./DSL/erase") 

(load  "./DSL/erase") 

(compile-file  "./DSL/menu") 

(load  "./DSL/menu") 

(compile-file  " ./DSL/display-files") 

(load  "./DSL/display-files") 

(coiiq>ile-f  ile  " .  /DSL/modif y-obj  ") 
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(load  " . /DSL/modif y-ob j " ) 


(compile-file  "./DSL/save") 

(load  "./DSL/save") 

(compile-file  "./DSL/generic") 

(load  "./DSL/generic") 

(compile-file  " . /DSL/build-generic") 
(load  "./DSL/build-generic") 

(compile-file  " ./DSL/complete") 

(load  " . /DSL/complete") 


(compile-file  "  ./OCTU/aet-debug") 

(load  "./OCU/aet-debug") 

(compile-file  " ./OCU/importa-exporta") 
(load  "./OCU/importa-exporta") 

(con^ile-f ile  " . /OCU/eval-expr") 

(load  " . /OCU/eval-expr" ) 

(compile-file  " ./OCU/execute") 

(load  "./OCU/execute") 

(compile-file  " ./OCU/aemantic-checka") 
(load  "./OCU/aemantic-checka") 
(compile-file  " ./domain-model/and-gate") 
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(load  " ./domain-model/and-gate") 


(compile-file  " ./domain-model /or-gate”) 

(load  " . /domain-model/or-gate") 

(compile-file  " ./domain-model/nand-gate") 
(load  " ./domain-model/nand-gate") 

(compile-file  " ./domain-model/nor-gate") 
(load  " . /domain-model/nor-gate") 

(compile-file  " ./domain-model/not -gate") 
(load  " . /domain-model/not-gate") 

(compile-file  " ./domain-model/svitch") 

(load  "./domain-model/switch") 

(compile-file  " ./domain-model/ jk-f lip-flop") 
(load  " ./domain-model/jk-f lip-flop") 

(compile-file  " ./domain-model/led") 

(load  " . /domain-model/led" ) 

(compile-file  " . /domain-model/counter") 

(load  "./domain-model/counter") 

(compile-file  " ./domain-model/decoder") 

(load  " . /domain-model/decoder" ) 

(compile-file  " ./domain-model/half -adder") 
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(load  " ./domain-model/half -adder") 

(compile-file  " . /domain-model/muz") 

(load  " . /domain-model /max " ) 

(compile-file  " ./domain-model/gram-logic") 
(load  " ./domain-model/gram- logic") 


(in-grammar  ’circuits) 

) 

Xend-Csinglespace} 
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Appendix  C.  Validation  Test  Cases  and  Results 


This  appendix  presents  a  subset  of  the  circuits  from  the  logic  circuit  domain  which 
were  constructed  to  demonstrate  the  utility  of  Architect,  the  application  generator  imple¬ 
mented  during  this  research.  Each  test  case  is  presented  in  the  following  consistent  format: 
the  objective  to  be  achieved,  an  illustration  of  the  circuit /application  to  be  tested,  the  ap¬ 
plication  specification  written  in  the  domain-specific  language  and  system/user  dialogues 
during  the  test.  Please  note:  the  system/user  dialogues  have  been  editted.  During  actual 
execution  of  Architect,  the  complete  list  of  possible  import  sources  is  presented  to  the  ap¬ 
plication  specialist  each  time  one  is  requested;  I  have  retained  only  the  first  such  display, 
deleting  the  repetitive  ones  to  conserve  paper. 
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C.l  Decoder  Test 


This  test  case  consists  of  two  independent  3-to-8  line  decoders:  one  constructed  from 
very  low-level  logic  gates  (AND,  NOT),  the  other  from  the  domain’s  decoder  primitive 
object.  Each  decoder  was  provided  the  same  input  values  to  demonstrate  the  equivalence 
of  the  two  circuits.  It  also  includes  a  second  execution  of  the  same  application  with 
different  input  values.  This  illustrates  two  points:  1)  the  application  works  correctly  with 
a  different  set  of  values  and  2)  a  different  user  interface  is  used  when  import-to-export 
connections  already  exist.  An  additional  point  should  be  noted:  the  primitive  decoder 
is  much  easier  to  use  than  the  one  constructed  from  low-level  logic  gates.  This  should 
be  a  fundamental  lesson  for  the  domain  engineer:  if  a  particular  subsystem  will  be  used 
repeatedly  by  application  specialists  working  within  the  domain,  it  may  be  advisable  to 
encapsulate  that  subsystem  into  a  “high-level  primitive”  to  simplify  subsequent  application 
specifications. 

C.1.1  Circuit  Diagram  See  Figure  C.l  for  a  decoder  implemented  as  a  subsystem 
composed  from  low-level  logic  gates.  Figure  C.2  illustrates  a  decoder  primitive.  Both  have 
been  included  in  the  specification  for  this  test  case. 

C.l. 2  Application  Specification  -  Test  1 


application  definition  test-decoders-primitive-and-snbsystem 


snitch  sub-z 
snitch  sub-y 
snitch  sub-x 
snitch  z 
snitch  y 
snitch  X 


position:  on 
position:  on 
position:  on 
position:  on 
position:  on 
position:  on 


not-gate  not-sub-z 
not-gate  not-snb-y 
not-gate  not-snb-x 


and-gate  andOl 
and-gate  and02 
and-gate  andll 
and-gate  andl2 
and-gate  and21 
axid-gate  and22 
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and-gate  andSl 
and-gatfl  and32 
and-gate  anddl 
and-gate  and42 
and-gat-e  andSl 
and-gate  and52 
and-gate  and61 
and-gate  and62 
and-gate  and71 
and-gate  cuid72 

led  sub-mO 
led  sub-ml 
led  8nb-m2 
led  sub-m3 
led  sub-m4 
led  sub-mS 
led  sub-m6 
led  sub-m7 

led  mO 
led  ml 
led  m2 
led  m3 
led  m4 
led  m5 
led  m6 
led  ml 


decoder  OECODEl 
application  decoder-tests  is 
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controls:  decoder-subsystem, 
decoder-pr imit ive 
update  procedure: 

update  decoder-subsystem 
update  decoder-primitive 

subsystem  decoder- subsystem  is 

controls:  sub-z,  sub-y,  sub-x,  not-sub-z,  not-sub-y,  not-sub-x, 

andOl,  and02,  emdll,  andl2,  2uid21,  and22,  andSl,  and32, 
and41,  and42,  andSl,  and52.  and61,  and62,  and71,  and72, 
sub-mO,  sub-ml,  sub-m2,  sub-m3,  sub-m4,  sub-mS,  sub-m6, 
sub-m7 

update  procedure: 
update  sub-z 
update  sub-y 
update  sub-x 
update  not-sub-z 
update  not-sub-y 
update  not-sub-x 
update  andOl 
update  and02 
update  andll 
update  andl2 
update  and21 
update  and22 
update  and31 
update  and32 
update  and4i 
update  and42 
update  andSl 
update  and52 
update  and61 
update  and62 
update  and71 
update  and72 
update  sub-mO 
update  sub-ml 
update  sub-m2 
update  sub-m3 
update  sub-m4 
update  sub-mS 
update  sub-m6 
update  sub-m7 

subsystem  decoder-primitive  is 

controls:  x,  y,  z,  DECODEl,  mO,  ml,  m2,  m3,  m4,  mS,  m6,  m7 
update  procedure: 
update  z 
update  y 
update  X 
update  DECODEl 


update  mO 
update  ml 
update  m2 
update  m3 
update  m4 
update  m5 
update  m6 
update  m7 


C.1.3  System/ User  Dialogue  -  Test  1 

.>  (#>  application  definition  test-decoders-primitive-cind-subsystem) 
application  definition 

TEST-DECODERS-PRIMITIVE-AHD-SUBSYSTEM 

SUB-Z  SUB-Y  SOB-X  Z  Y  X  lOT-SUB-Z  HOT-SUB-Y  MOT-SUB-X  AIDOl 
AHD02  AIDll  AII)12  AVD21  AHD22  AND31  AHD32  AHD41  AID42  AHD51 
AHDS2  AID61  AHD62  A1D71  AHD72  SUB-MO  SUB-MI  SUB-M2  SUB-M3 
SUB-M4  SUB-MS  SUB-M6  SUB-M7  MO  Ml  M2  M3  M4  MS  M6  M7  DECODEl 
DECODER-TESTS  DECODER-SUBSYSTEM  DECODER-PRIMITIVE 
•>  (rs) 

-  Rules  for:  application  definition 
TEST-DECODERS-PRIMITIVE-AID-SUBSYSTEM 

SUB-Z  SUB-Y  SUB-X  Z  Y  X  HOT-SUB-Z  HOT-SUB-Y  HOT-SUB-X  AHDOl 
AHD02  AHDll  AID12  AHD21  AHD22  AH031  AID32  AHD41  AND42  AHDSl 
ABD52  AID61  AHD62  AID71  AID72  SUB-MO  SUB-MI  SUB-M2  SUB-M3 
SUB-M4  SUB-MS  SUB-M6  SUB-M7  MO  Ml  M2  M3  M4  MS  M6  M7  DECODEl 
DECODER-TESTS  DECODER-SUBSYSTEM  DECODER-PRIMITIVE  - 
2)  CHECK-SEMAHTICS 
•>  (ar  2) 


More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  SUB-M7 

in  subsystem  DECODER-SUBSYSTEM 
Choose  the  export  item  (subsystem  and  component) 
that  you  wish  to  be  the  source  of  this  data: 


1>  subsystem  "DECODER-SUBSYSTEM"  component  " 
2>  subsystem  "DECODER-SUBSYSTEM"  component  " 
3>  subsystem  "DECODER-SUBSYSTEM"  component  " 
4>  subsystem  "DECODER-SUBSYSTEM"  component  " 
6>  subsystem  "DECODER-SUBSYSTEM"  component  " 
6>  subsystem  "DECODER-SUBSYSTEM"  component  " 
7>  subsystem  "DECODER-SUBSYSTEM"  component  " 
8>  subsystem  "DECODER-SUBSYSTEM"  component  " 
9>  subsystem  "DECODER-SUBSYSTEM"  component  " 
10>  subsystem  "DECODER-SUBSYSTEM"  component 
11>  subsystem  "DECODER-SUBSYSTEM"  component 
12>  subsystem  "DECODER-SUBSYSTEM"  component 
13>  subsystem  "DECODER-SUBSYSTEM"  component 
14>  subsystem  "DECODER-SUBSYSTEM"  component 
1&>  subsystem  "DECODER-SUBSYSTEM"  component 
16>  subsystem  "DECODER-SUBSYSTEM"  component 


SUB-Z"  name  "OUTl" 
SUB-Y"  name  "OUTl" 
SUB-X"  name  "OUTl" 
lOT-SUB-Z"  name  "OUTl 
lOT-SUB-Y"  name  "OUTl 
lOT-SUB-X"  name  "OUTl 
AIDOl"  name  "OUTl" 
AID02"  name  "OUTl" 
AIDll"  name  "OUTl" 


"AID12" 

name 

"OUTl" 

"AID21" 

name 

"OUTl" 

"AID22" 

name 

"OUTl" 

"AID31" 

name 

"OUTl" 

"AID32" 

name 

"OUTl" 

"AID41" 

name 

"OUTl" 

"AID42" 

name 

"OUTl" 

M 


M 

M 
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17> 

18> 

19> 

20> 

21> 

22> 

23> 

24> 

26> 

26> 

27> 

28> 

29> 

30> 

31> 

32> 

33> 

34> 

Enter  the 

22 


subsystem  "DECODER-SUBSYSTEM"  component  "AHD51"  name  "OUTl" 
subsystem  "DECODER-SUBSYSTEM"  component  "AHD52"  name  "OUTl" 
subsystem  "DECODER-SUBSYSTEM"  component  "AHD61"  name  "OUTl" 
subsystem  "DECODER-SUBSYSTEM"  component  "AHD62"  name  "OUTl" 
subsystem  "DECODER- SUBSYSTEM"  component  "AHD71"  name  "OUTl" 
subsystem  "DECODER-SUBSYSTEM"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component 
subsystem  "DECODER-PRIMITIVE"  component  "DECODEl"  name  "M7" 
Specific  source  not  required;  use  arbitr2ury  one 
number  corresponding  to  the  source  you  want  to  use 


"AID72"  name  "OUTl 

"X"  name  "OUTl" 

"Y"  name  "OUTl" 

"Z"  name  "OUTl" 

"DECODEl" 

name 

"MO 

"DECODEl" 

name 

"Ml' 

"DECODEl" 

name 

"M2 

"DECODEl" 

name 

"MS' 

"DECODEl" 

name 

"M4 

"DECODEl" 

name 

"MS' 

"DECODEl" 

name 

"M6 

"DECODEl" 

name 

"M7' 

More  than 


Enter  the 
20 


one  export  can  provide  the  data  for  III 

vhich  is  used  by  object  SUB-M6 

in  subsystem  DECODER-SUBSYSTEM 
number  corresponding  to  the  source  you  uant  to  use 


More  than  one  export  can  provide  the  data  for  III 

vhich  is  used  by  object  SUB-MS 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  ntunber  corresponding  to  the  source  you  want  to  use 
18 


More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  SUB-M4 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  weuit  to  use 
16 


More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  SUB-M3 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
14 


More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  SUB-M2 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
12 
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More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  SUB-MI 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
10 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  SUB-MO 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
8 

More  th2ui  one  export  can  provide  the  data  for  IH2 

which  is  used  by  object  AND72 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  A1D72 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
21 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  AID71 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  A1D71 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
1 

More  than  one  export  can  provide  the  data  for  IN2 

which  is  used  by  object  AND62 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  AID62 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
19 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  AHD61 

in  subsystem  DECODER-SUBSYSTEM 
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Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 


More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  AID61 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

4 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  A1D62 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  Ill 

which  is  used  by  object  AIDS2 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
17 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  AID51 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

5 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  A1D51 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
1 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  AID42 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  AID42 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
16 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  AID41 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
S 
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More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AHD41 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
4 

More  than  one  export  can  provide  the  data  lor  IH2 

which  is  used  by  object  A1D32 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  lor  IHl 

which  is  used  by  object  AID32 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
13 

More  than  one  export  can  provide  the  data  lor  II2 

which  is  used  by  object  A1D31 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AHD31 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  yon  want  to  use 
1 

More  than  one  export  can  provide  the  data  lor  II2 

which  is  used  by  object  ARD22 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AID?2 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
11 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  AID21 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AID21 

in  subsystem  DECODER-SUBSYSTEM 
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Enter  the  number  corresponding  to  the  source  you  uant  to  use 
4 


More  than  one  export  can  provide  the  data  lor  112 

uhich  is  used  by  object  AID12 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  U3mt  to  use 
6 

More  than  one  export  can  provide  the  data  lor  III 

uhich  is  used  by  object  A1D12 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  uant  to  use 
9 

More  than  one  export  can  provide  the  data  lor  112 

uhich  is  used  by  object  AIDll 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

5 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AIDll 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
1 

More  than  one  export  can  provide  the  data  lor  IH2 

which  is  used  by  object  A1D02 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

6 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AID02 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
7 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  AIDOl 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 


More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AIDOl 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
4 
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Mor«  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  MOT-SUB-X 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  lOT-SUB-Y 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  lOT-SUB-Z 

in  subsystem  DECODER-SUBSYSTEM 

Enter  the  number  corresponding  to  the  source  you  W2uit  to  use 
1 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  M7 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
33 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  M6 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
32 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  MS 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
31 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  M4 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
30 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  M3 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
29 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  M2 

in  subsystem  DECODER-PRIMITIVE 


C-12 


Enter  the  number  corresponding  to  the  source  you  sent  to  use 
28 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  Ml 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
27 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  MO 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 


More  than  one  export  can  provide  the  data  lor  113 

which  is  used  by  object  DECODEl 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
25 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  DECODEl 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
24 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  DECODEl 

in  subsystem  DECODER-PRIMITIVE 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
23 

Rule  successlully  applied, 
application  delinition 
TEST-DECODERS-PRINITIVE-AID-SUBSYSTEM 

SOB-Z  SUB-Y  SUB-X  Z  Y  X  lOT-SUB-Z  lOT-SOB-Y  lOT-SUB-X  lIDOl 
AI002  AIDll  AID12  AID21  AID22  AID31  AID32  AID41  AID42  AID51 
AID52  AID61  AXD62  AID71  AID72  SUB-MO  SUB-MI  SUB-M2  SUB-M3 
SUB-N4  SUB-N5  SUB-N6  SUB-N7  NO  Ml  N2  N3  N4  MB  M6  N7  DECODEl 
DECODER-TESTS  DECODER-SUBSYSTEM  DECODER-PRIMITIVE 
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C.2  Full  Adder  Test 


This  case  tests  a  full  adder.  It  is  constructed  of  two  half  adders:  one  is  a  subsystem 
composed  of  low-level  primitives,  the  other  is  the  domain’s  “higher  level  primitive.”  This 
test  demonstrates  the  interchangeability  of  subsystem  versus  “higher  level  primitives”  in 
application  specifications. 

C.2.1  Circuit  Diagram  See  Figure  C.3. 


Figure  C.3.  Full  Adder 


C.2. 2  Application  Specification 
application  definition  test-full-adder 

snitch  X  position:  on 
snitch  y  position:  on 
snitch  carry-in  position:  off 

not-gate  not-x 
not-gate  not-y 

and-gate  andl 
and-gate  and2 
and-gate  and3 

or-gate  orl 
or-gate  or2 


C-14 


led  8 
led  c 


ball-adder  HA2 

application  lull-adder-test  is 
controls:  lull-adder 
update  procedure: 

update  lull-adder 

subsystem  lull-adder  is 

controls:  hall-adder-subsystem.  HA2.  or2.  carry-in.  s.  c 
update  procedure: 
update  carry- in 
update  hall-adder-subsystem 
update  HA2 
update  or 2 
update  s 
update  c 

subsystem  hall-adder-subsystem  is 

controls:  r.  y.  not-x.  not-y.  andl.  and2.  and3.  orl 
update  procedure: 
update  z 
update  not-z 
update  y 
update  not-y 
update  andl 
update  and2 
update  orl 
update  and3 


C.2.3  System/User  Dialogue 


.>  (#>  application  delinition  test-lull-adder) 
application  delinition  TEST-FULL-ADDER 

X  Y  CARRY-II  lOT-X  lOT-Y  AIDl  AID2  A1D3  ORl  0R2  S  C  HA2 
FULL-ADDER-TEST  FULL-ADDER  HALF-ADDER-SUBSYSTEM 
•>  (rs) 

-  Rules  lor:  application  delinition  TEST-FULL-ADDER 

X  Y  CARRY-II  lOT-X  lOT-Y  AIDl  AID2  AID3  ORl  0R2  S  C  HA2 
FULL-ADDER-TEST  FULL-ADDER  HALF-ADDER-SUBSYSTEM  - 
2)  CBECK-SEMAITICS 
.>  (ar  2) 

More  than  one  export  can  provide  the  data  lor  III 

vhicb  is  used  by  object  C 


CIS 


in  subsystem  FULL-ADDER 

Choose  the  export  item  (subsystem  and  component) 
that  you  «ish  to  be  the  source  ol  this  data: 

1>  subsystem  "FULL-ADDER”  component  "HA2"  name  "S" 

2>  subsystem  "FULL-ADDER"  component  "HA2"  name  "C" 

3>  subsystem  "FULL-ADDER"  component  '•0R2"  name  "OUTl" 

4>  subsystem  "FULL-ADDER"  component  "CARRY-II"  name  "OUTl" 

6>  subsystem  "HALF- ADDER-SUBSYSTEM"  component  "X"  name  "OUTl" 

6>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "Y"  name  "OUTl" 

7>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "HOT-X"  name  "OUTl" 
8>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "HOT-Y"  name  "OUTl" 
9>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "AHDl"  name  "OUTl" 
10>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "AHD2"  name  "OUTl" 
11>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "AID3"  name  "OUTl" 
12>  subsystem  "HALF-ADDER-SUBSYSTEM"  component  "ORl"  name  "OUTl" 
13>  Specific  source  not  required;  use  arbitrary  one 

Enter  the  number  corresponding  to  the  source  you  vant  to  use 

3 

More  than  one  export  can  provide  the  data  for  III 

vhich  is  used  by  object  S 

in  subsystem  FULL-ADDER 

Enter  the  number  corresponding  to  the  source  you  sant  to  use 

1 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  0R2 

in  subsystem  FULL-ADDER 

11 

Mora  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  0R2 

in  subsystem  FULL-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

2 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  HA2 

in  subsystem  FULL-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

4 

More  than  one  export  can  provide  the  data  for  IHl 

which  is  used  by  object  HA2 

in  subsystem  FULL-ADDER 

Enter  the  number  corresponding  to  the  source  you  wemt  to  use 

12 

More  than  one  export  can  provide  the  data  for  IH2 

which  is  used  by  object  ORl 

in  subsystem  BALF-ADDER-SUBSYSTEN 
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Enter  the  number  corresponding  to  the  source  you  sent  to  use 
10 


More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  ORl 

in  subsystem  HALF-ADDER-SUBSYSTEM 
Enter  the  number  corresponding  to  the  source  you  W2ait  to  use 
9 

More  than  one  export  can  provide  the  data  for  IH2 

which  is  used  by  object  AHD3 

in  subsystem  HALF-ADDER-SUBSYSTEM 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  AIDS 

in  subsystem  HALF-ADDER-SUBSYSTEN 
Enter  the  number  corresponding  to  the  source  you  want  to  use 

5 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  AID2 

in  subsystem  HALF-ADDER-SUBSYSTEM 
Enter  the  number  corresponding  to  the  source  you  want  to  use 

6 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  AID2 

in  subsystem  HALF-ADDER-SUBSYSTEN 
Enter  the  number  corresponding  to  the  source  you  want  to  use 

7 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  AIDl 

in  subsystem  HALF-ADDER-SUBSYSTEM 
Enter  the  number  corresponding  to  the  source  you  want  to  use 

8 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  AHDl 

in  subsystem  HALF-ADDER-SUBSYSTEN 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  lOT-Y 

in  subsystem  HALF-ADDER-SUBSYSTEN 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 
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More  than  one  export  can  provide  the  data  for  IHl 

Bhich  is  used  by  object  HOT-X 

in  subsystem  HALF-ADDER-SUBSYSTEM 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
5 

Rule  successfully  applied, 
application  definition  TEST-FULL- ADDER 

X  y  CARRY-II  lOT-X  SCT-Y  AIDl  AID2  AIDS  ORl  0R2  S  C  HA2 
FULL-ADDER-TEST  FULL-ADDER  HALF-ADDER-SUBSYSTEM 
.>  (rs) 

-  Rules  for:  application  definition  TEST-FULL-ADDER 

X  Y  CARRY-II  lOT-X  lOT-Y  AIDl  AID2  AIDS  ORl  0R2  S  C  HA2 
FULL-ADDER-TEST  FULL-ADDER  HALF-ADDER-SUBSYSTEM  - 

1)  DO-EXECUTE 

2)  CHECK-SEMAITICS 
.>  (ar  1) 

LED  S  =  OFF 
LED  C  =  01 

Rule  successfully  applied, 
application  definition  TEST-FULL- ADDER 

X  Y  CARRY-II  lOT-X  lOT-Y  AIDl  A1D2  AIDS  ORl  0R2  S  C  HA2 
FULL-ADDER-TEST  FULL-ADDER  HALF-ADDER-SUBSYSTEM 
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C.3  BCD  Adder 


This  test  case  constructs  a  circuit  which  can  be  used  to  add  two  one-digit  decimal 
numbers.  Note  that  one-digit  decimal  number  can  range  from  0  -  9;  therefore  four  binary 
bits  are  needed  for  its  computer  representation  which  is  called  Binary  Coded  Decimal  or 
BCD.  Table  C.l  provides  a  comparison  between  BCD  and  binary  number  representations 
(27:250).  It  can  be  used  to  verify  the  results  of  the  constructed  circuit. 


Table  C.l.  BCD/Binary  Comparison 
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C.3.1  Circuit  Diagram  See  Figure  C.4  ,(27:252). 
C.3. 2  Application  Specification 


application  definition  test-BCD-adder 


snitch  aO 

position: 

on 

snitch  al 

position: 

oil 

snitch  a2 

position: 

oil 

snitch  a3 

position: 

on 

C-19 


Figure  C.4.  BCD  Adder 


SHitch  bO  position:  on 
snitch  bl  position:  off 
snitch  b2  position:  oil 
snitch  b3  position:  on 

snitch  cOiTry-in  position:  oil 

snitch  zero  position:  oil 

hall-adder  HAlll 
hall-adder  HA112 
hall-adder  HA121 
hall-adder  HA122 
heLLl-adder  HA131 
hedl-adder  HA132 
hall-adder  HA141 
hall-adder  HA142 

hall-adder  HA211 
hall-adder  HA212 
hall-adder  HA221 
hall-adder  HA222 
hall-adder  HA231 
hall-adder  HA232 
hall-adder  RA241 
hall-adder  BA242 

or-gate  orlll 
or-gate  orl21 
or-gate  orl31 
or-gate  orl41 
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or-gate  or211 
or-gate  or221 
or-gate  or 231 
or-gate  or241 

or-gate  orl 
or-gate  or 2 

and-gate  andl 
and-gate  aiid2 

led  si 
led  s2 
led  s4 
led  s8 

led  carry-out 

application  BCD-adder-test  is 
controls;  BCD-adder 
update  procedure: 
update  BCD-adder 

subsystem  BCD-adder  is 

controls:  lour-bit-adderl ,  loiir-bit-adder2, 
andl,  and2,  orl,  or2, 

aO,  al,  a2,  a3,  bO,  bl,  b2,  b3,  carry-in,  zero, 
si,  s2,  s4,  s8,  carry-out 
update  procedure: 
update  aO 
update  al 
update  a2 
update  a3 
update  bO 
update  bl 
update  b2 
update  b3 
update  carry-in 
update  lour-bit-adderl 
update  andl 
update  and2 
update  orl 
update  or 2 
update  zero 
update  lour-bit-adder2 
update  si 
update  s2 
update  s4 
update  s8 
update  carry-out 
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subsystem  four-b it- adder 1  is 

controls:  full-adder 111,  full-adderl21,  f ull-adderl31 ,  full-adderl41 
update  procedure : 

update  full-adderlll 
update  full-adderl21 
update  full-adderl31 
update  full-adderl41 

subsystem  full-adderlll  is 

controls:  HAlll,  HA112,  orlll 

update  procedure: 
update  HAlll 
update  HA112 
update  orlll 

subsystem  full-adderl21  is 

controls:  HA121,  HA122,  orl21 

update  procedure: 
update  HA121 
update  HA122 
update  orl21 

subsystem  full-adderl31  is 

controls:  HA131,  HA132,  orl31 

update  procedure: 
update  HA131 
update  HA132 
update  orl31 


subsystem  full-adderl41  is 

controls:  HA141,  HA142,  orl41 

update  procedure: 
update  HA141 
update  HA142 
update  orl41 


subsystem  four-bit-adder2  is 

controls:  full-adder211,  full-adder 221,  full-adder231 ,  full-adder241 
update  procedure: 

update  full-adder211 
update  full-adder221 
update  full-adder231 
update  full-adder241 


subsystem  full-adder211  is 

controls:  HA211,  HA212,  or211 

update  procedure: 
update  HA211 
update  HA212 
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update  or211 


subsystem  full-adder221  is 

controls:  HA221,  HA222,  or221 
update  procedure: 
update  HA221 
update  HA222 
update  or221 

subsystem  lull-adder231  is 

controls:  HA231,  HA232,  or231 

update  procedure: 
update  HA231 
update  HA232 
update  or231 

subsystem  full-adder241  is 

controls:  HA241,  HA242,  or241 
update  procedure: 
update  HA241 
update  HA242 
update  or241 

C.3.3  System/User  Dialogue 


,>  (#>  application  definition  test-BCD-adder) 
application  definition  TEST-BCD-AODER 

AO  A1  A2  A3  BO  B1  B2  B3  CARRY-IH  ZERO  BAlll  HA112  HA121 

HA122  HA131  HA132  HA141  HA142  BA211  BA212  BA221  BA222  BA231 

BA232  BA241  BA242  ORlll  0R121  0R131  0R141  0R211  0R221  0R231 

0R241  ORl  0R2  AlDl  A1D2  SI  S2  S4  SB  CARRY-OUT 
BCD- ADDER-TEST  BCD- ADDER  FOUR-BIT- ADDERl  FULL-ADDERlll 
FULL-ADDER121  FUIX-ADDER131  FULL-ADDEB141  F0UB-BIT-ADDER2 
FULL-ADDER2il  FULL-ADDER221  FULL-ADDER231  FULL-ADDER241 
•>  (rs) 

-  Rules  for:  application  definition  TEST-BCD-ADDER 

AO  A1  A2  A3  BO  B1  B2  B3  CARRY-II  ZERO  BAlll  EA112  HA121 

BA122  BA131  BA132  BA141  BA142  BA211  BA212  BA221  HA222  BA231 

BA232  BA241  EA242  ORlll  0R121  0R131  0R141  0R211  0R221  0R231 

0R241  ORl  0R2  AIDl  AID2  SI  S2  S4  SB  CARRY-OUT 
BCD-ADDER-TEST  BCD-ADDER  FOUR-BIT-ADDERl  FULL-ADDERlll 
FULL-ADDER121  FULL-ADDER131  FULL-ADDER141  F0UR-BIT-ADDER2 
FULL-ADDER211  FULL-ADDER221  FULL-ADDEB231  FULL-ADDER241  - 
2)  CBECX-SEMAITICS 
.>  (ar  2) 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  CARRY-OUT 
in  subsystem  BCD-ADDER 
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Cboose  the  export  item  (subsystem  and  component) 
that  yon  wish  to  be  the  source  ol  this  data: 

1>  subsystem  "BCD-ADOER"  component  "ilDl"  name  "OUTl" 

2>  subsystem  "CCD-ADDER"  component  "An)2"  name  "OUTl" 

3>  subsystem  "BCD-ADDER"  component  "ORl"  name  "OUTl" 

4>  subsystem  "BCD-ADDER"  component  "0R2"  name  "OUTl" 

S>  subsystem  "BCD-ADDER"  component  "AO"  name  "OUTl" 

6>  subsystem  "BCD-ADDER"  component  "Al"  name  "OUTl" 

7>  subsystem  "BCD-ADDER"  component  "A2"  name  "OUTl" 

8>  subsystem  "BCD-ADDER"  component  "A3"  name  "OUTl" 

9>  subsystem  "BCD-ADDER"  component  "BO"  name  "OUTl" 

10>  subsystem  "BCD-ADDER"  component  "Bl“  name  "OUTl" 

11>  subsystem  "BCD-ADDER"  component  "B2”  name  "OUTl" 

12>  subsystem  "BCD-ADDER"  component  "B3"  name  "OUTl" 

13>  subsystem  "BCD-ADDER"  component  "CARRY-IR"  name  "OUTl" 
14>  subsystem  "BCD-ADDER"  component  "ZERO"  name  "OUTl" 

15>  subsystem  "FULL-ADDERlll"  component  "HAlll"  name  "S" 

16>  subsystem  "FULL-ADDERlll"  component  "HAlll"  name  "C" 

17>  subsystem  "FULL-ADDERlll"  component  "HA112"  name  "S" 

18>  subsystem  "FULL-ADDERlll"  component  "HA112"  name  "C" 

19>  subsystem  "FULL-ADDERlll"  component  "ORlll"  name  "OUTl" 
20>  subsystem  "FULL-ADDER121"  component  "HA121"  name  "S" 

21>  subsystem  "FULL-A0DER121"  component  "HA121"  name  "C" 

22>  subsystem  "FULL-ADDER121"  component  "HA122"  name  "S" 

23>  subsystem  "FULL-ADDER121"  component  "HA122"  name  "C" 

24>  subsystem  "FULL-ADDER121"  component  "0R121"  name  "OUTl" 
26>  subsystem  "FULL-AODER131"  component  "HA131"  name  "S" 

26>  subsystem  "FULL-ADDER131"  component  "HA131"  name  "C" 

27>  subsystem  "FULL-ADDER131"  component  "HA132"  name  "S" 

28>  subsystem  "FULL-ADDER131"  component  "HA132"  name  "C" 

29>  subsystem  "FULL-AODER131"  component  "0R131"  name  "OUTl" 
30>  subsystem  "FULL-ADDER141"  component  "HA141"  name  "S" 

31>  subsystem  "FULL-A00ER141"  component  "HA141"  name  "C" 

32>  subsystem  "FULL-A0DER141"  component  "HA142"  name  "S" 

33>  subsystem  "FULL-ADDER141"  component  "HA142"  name  "C" 

34>  subsystem  "FULL-A0DER141"  component  "0R141"  name  "OUTl" 
36>  subsystem  "FULL-A0DER211"  component  "HA211"  name  "S" 

36>  subsystem  "FULL-ADDER211"  component  "HA211"  name  "C" 

37>  subsystem  "FULL-ADDER211"  component  "HA212"  name  "S" 

38>  subsystem  "FULL-A0DER211"  component  "HA212"  name  "C" 

39>  subsystem  "FULL-ADDER211"  component  "0R211"  name  "OUTl" 
40>  subsystem  "FULL-AODER221"  component  "HA221"  name  "S" 

41>  subsystem  "FULL-ADDER221"  component  "HA221"  name  "C" 

42>  subsystem  "FULL-ADDER221"  component  "HA222"  name  "S" 

43>  subsystem  "FULL-A0DER221"  component  "HA222"  name  "C" 

44>  subsystem  "FULL-ADDER221"  component  "0R221"  name  "OUTl" 
45>  subsystem  "FULL-ADDER231"  component  "HA231"  name  "S" 

46>  subsystem  "FULL-A00ER231"  component  "HA231"  name  "C" 

47>  subsystem  "FULL-ADDER231"  component  "HA232"  name  "S" 

48>  subsystem  "FULL-ADDER231"  component  "HA232"  name  "C" 

49>  subsystem  "FULL-ADDER231”  component  "0R231"  name  "OUTl" 
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60>  subsystem  "FUL1.-A0DER241''  component  "HA241"  name  "S" 

51>  subsystem  "FTJIX-ADDER241'‘  component  "HA241"  name  "C" 

S2>  subsystem  "FULL-ADDER241"  component  "HA242"  name  "S" 

53>  subsystem  "FULL-ADDER241"  component  ''HA242"  name  "C" 

&4>  subsystem  "FULL-ADDER24i"  component  "0R241"  name  "OUTl" 
5S>  Specific  source  not  required;  use  arbitrary  one 
Enter  the  number  corresponding  to  the  source  you  sant  to  use 
4 

More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  S8 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  sant  to  use 
52 

More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  S4 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
47 

More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  S2 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
42 

More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  SI 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
37 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  0R2 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  0R2 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
34 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  ORl 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 
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Nora  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  ORl 

in  subsystem  BCD-ADDER 

Enter  the  nunber  corresponding  to  the  source  you  want  to  use 
1 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  AID2 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
22 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  A1D2 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
32 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  AIDl 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
27 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  AlDl 

in  subsystem  BCD-ADDER 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
32 

More  than  one  export  can  provide  the  data  lor  II2 

which  is  used  by  object  ORlll 

in  subsystem  FULL-ADDERlll 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
18 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  ORlll 

in  subsystem  FULL-ADDERlll 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
16 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  HA112 

in  subsystem  FULL-ADDERlll 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
13 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  HA112 

in  subsystem  FULL-ADDERlll 
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Enter  tbe  number  corresponding  to  the  source  you  want  to  use 
15 


More  than  one  export  can  provide  the  data  lor  112 

uhich  is  used  by  object  HAlll 

in  subsystem  FULL-ADDERlll 

Enter  the  number  corresponding  to  the  source  you  sant  to  use 

9 

More  than  one  export  can  provide  the  data  for  111 

which  is  used  by  object  HAlll 

in  subsystem  FULL-ADDERlll 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  0R121 

in  subsystem  FULL-ADDER121 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
23 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  0R121 

in  subsystem  FULL-ADDER121 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
21 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  HA122 

in  subsystem  FULL-ADDER121 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

19 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  HA122 

in  subsystem  FULL-ADDER121 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

20 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  HA121 

in  subsystem  FULL-ADDER121 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

10 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  HA121 

in  subsystem  FULL-ADDER121 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 
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More  than  one  export  can  provide  the  data  lor  II2 

which  is  used  by  object  0R131 

in  subsystem  FULL-ADDER131 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
28 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  0R131 

in  subsystem  FULL-ADDER131 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
26 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  HA132 

in  subsystem  FIILL-ADDER131 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

24 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  HA132 

in  subsystem  FULL-ADDER131 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

25 

More  than  one  export  can  provide  the  data  lor  II2 

which  is  used  by  object  HA131 

in  subsystem  FULL-A0DER131 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
11 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  HA131 

in  subsystem  FULL-ADDER131 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
7 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  □R141 

in  subsystem  FULL-ADDER141 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
33 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  0R141 

in  subsystem  FULL-AD0ER141 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
31 

More  than  one  export  can  provide  the  data  lor  112 

which  is  used  by  object  HA142 

in  subsystem  FULL-A0DER141 
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Enter  the  number  corresponding  to  the  source  you  uauit  to  use 

29 

More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  HA142 

in  subsystem  FULL-ADDER141 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

30 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  HA141 

in  subsystem  FULL-ADDER141 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
12 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  HA141 

in  subsystem  FULL-ADDER141 

Enter  the  number  corresponding  to  the  source  yon  want  to  use 
8 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  0R211 

in  subsystem  FULL-ADDER211 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
38 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  0R211 

in  subsystem  FULL-ADDER211 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
36 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  HA212 

in  subsystem  FULL-A0DER211 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
14 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  HA212 

in  subsystem  FULL-ADDER211 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
35 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  HA211 

in  subsystem  FULL-ADDER211 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
14 
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Nor«  than 


Enter  the 
17 

More  than 


Enter  the 
43 

More  than 


Enter  the 
41 

More  than 


Enter  the 
39 

More  than 


Enter  the 
40 

More  than 


Enter  the 
4 

More  than 


Enter  the 
22 

More  than 


Enter  the 
48 

More  than 


one  export  can  provide  the  data  for  III 

shich  is  used  by  object  HA211 

in  subsystem  FULL-ADDER211 
number  corresponding  to  the  source  you  uant  to  use 


one  export  can  provide  the  data  for  112 

nhich  is  used  by  object  0R221 

in  subsystem  FULL-A0DER221 
number  corresponding  to  the  source  you  uant  to  use 


one  export  can  provide  the  data  for  Ill 

uhich  is  used  by  object  0R221 

in  subsystem  FULL-A0DER221 
number  corresponding  to  the  source  you  uant  to  use 


one  export  can  provide  the  data  for  112 

uhich  is  used  by  object  HA222 

in  subsystem  FULL-ADDER221 
niuaber  corresponding  to  the  source  you  usmt  to  use 


one  export  can  provide  the  data  for  Ill 

which  is  used  by  object  BA222 

in  subsystem  FULL-ADDER221 
number  corresponding  to  the  source  you  want  to  use 


one  export  can  provide  the  data  for  112 

which  is  used  by  object  HA221 

in  subsystem  FULL-ADDER221 
number  corresponding  to  the  source  you  want  to  use 


one  export  can  provide  the  data  for  Ill 

which  is  used  by  object  HA221 

in  subsystem  FULL-A0DER221 
number  corresponding  to  the  source  you  want  to  use 


one  export  can  provide  the  data  for  112 

which  is  used  by  object  0R231 

in  subsystem  FULL-ADDER231 
number  corresponding  to  the  source  you  want  to  use 


one  export  can  provide  the  data  for  Ill 

which  is  used  by  object  01231 

in  subsystem  FUII.-A0DER231 
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Enter  the  number  corresponding  to  the  source  you  sent  to  use 
46 

More  than  one  export  can  provide  the  data  for  II2 

Bhich  is  used  by  object  HA232 

in  subsystem  FULL-ADDER231 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

44 

More  than  one  export  can  provide  the  data  for  IHl 

which  is  used  by  object  HA232 

in  subsystem  FULL-ASDER231 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

45 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  HA231 

in  subsystem  FULL-ADDER231 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
4 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  HA231 

in  subsystem  FULL-ADDER231 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
27 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  0R241 

in  subsystem  FULL-A0DER241 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
S3 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  0R241 

in  subsystem  FULL-ADDER241 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
61 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  HA242 

in  subsystem  FULL-A0DER241 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
49 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  HA242 

in  subsystem  FULL-ADDER241 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
60 
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More  than  one  export  can  provide  the  data  lor  IH2 

vhich  is  used  by  object  HA241 

in  subsystem  FULL-ADDER241 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
14 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  HA241 

in  subsystem  FULL-ADDER241 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
32 

Rule  successlully  applied, 
application  delinition  TEST-BCD-AODER 

AO  A1  A2  A3  BO  B1  B2  B3  CARRY-II  ZERO  HAlll  HA112  HA121 

HA122  HA131  HA132  HA14i  HA142  HA211  HA212  HA221  HA222  HA231 

HA232  HA241  HA242  ORlll  0R121  0R131  0R141  0R211  0R221  0R231 

0R241  QRl  0R2  AIDl  AID2  SI  S2  S4  S8  CARRY-OUT 
BCD- ADDER-TEST  BCD-ADDER  FOUR-BIT-ADDERl  FUIl-ADDERl 1 1 
FULL-ADDERIZI  F0LL-ADDER131  FULL-ADDER141  F0UR-BIT-ADDER2 
FULL-ADDER211  FULL-ADDER221  FULL-ADDER231  FULL-ADDER241 
.>  (ra) 

-  Rules  lor:  application  delinition  TEST-BCD-ADDER 

AO  A1  A2  A3  BO  B1  B2  B3  CARRY-Il  ZERO  BAlll  HA112  HA121 

HA122  HA131  HA132  HA141  HA142  BA21i  HA212  HA221  BA222  BA231 

BA232  BA241  BA242  ORlll  0R121  0R131  0R141  0R211  0R221  0R231 

0R241  ORl  0R2  AIDl  AID2  SI  S2  S4  S8  CARRY-OUT 
BCD-ADDER-TEST  BCD-ADDER  FOUR-BlT-ADDERl  FULL-ADDERlll 
FULL-ADDER121  F0LL-ADDER131  FULL-ADDEB141  F0UR-BIT-ADDER2 
FULL-ADDER211  FULL-ADDER221  FULL-ADDER231  FULL-ADDER241  - 
1)  DO-EXECUTE 
2}  CBECK-SEMAITICS 
.>  (ar  1) 

LED  SI  =  OFF 

LED  S2  =  OFF 

LED  S4  =  OFF 

LED  S8  =  01 

LED  CARRY-OUT  =  01 

Rule  successlully  applied. 

application  delinition  TEST-BCD-ADDER 

AO  A1  A2  A3  BO  B1  B2  B3  CARRY-II  ZERO  HAlll  BA112  HA121 

EA122  HA131  EA132  BA141  BA142  BA211  EA212  HA221  HA222  HA231 
BA232  HA241  BA242  ORlll  0R121  0R131  0R141  0R211  0R221  0R231 
0E241  ORl  0R2  AIDl  AID2  SI  S2  S4  S8  CARRY-OUT 
BCD-ADDER-TEST  BCD-ADDER  FOUR-BIT-ADDERl  FULL-ADDERlll 
FULL-ADDER121  FULL-ADDER131  FULL-ADDER141  F0UR-BIT-ADDER2 
FULL-ADDER211  FULL-ADDER221  FULL-ADDER231  FULL-ADDER241 
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C.^  2x2  Binary  Array  Multiplier 

This  test  case  presents  a  circuit  for  multiplying  two  2-digit  binary  numbers.  It  is 
based  on  the  following  formula  (27:365): 


bl  bO 
al  aO 


aObl  aObO 
albl  albO 


c3  c2  cl  cO 


C.4.1  Circuit  Diagram  See  Figure  C.5  (27:365). 


C.4'2  Application  Specification 


application  definition  test-2x2-binary-array-mttltiplier 


snitch  aO 
snitch  al 
snitch  bO 
snitch  bl 


position:  on 
position:  on 
position:  on 
position:  on 


and-gate  andl 
and-gate  and2 
and-gate  and3 
and-gate  and4 

half-adder  HAl 
half-adder  HA2 


led  cO 
led  cl 
led  c2 
led  c3 


application  binary-array-test  is 
controls:  binary-array 
update  procedure: 

update  binary-array 

subsystem  binary-array  is 
controls:  aO,  al,  bO,  bl. 
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Figure  C.5.  2x2  Binary  Array  Multiplier 


andl,  aiid2,  andS,  aiid4. 

HAl.  HA2. 
cO,  cl,  c2,  c3 
update  procedure: 
update  aO 
update  al 
update  bO 
update  bl 
update  andl 
update  cO 
update  and2 
update  eindS 
update  HAl 
update  cl 
update  and4 
update  HA2 
update  c2 
update  c3 

C.4-3  System/User  Dialogue 

.>  (#>  application  definition  tost-2i2-binary-array-multiplier) 
application  definition  TEST-2X2-BIIARY-ARRAY-MULTIPLIER 
AO  Al  BO  Bl  AIDl  AHD2  AID3  AID4  HAl  HA2  CO  Cl  C2  C3 
BIIARY-ARRAY-TEST  BIIARY-ARRAY 
>  (rs) 

-  Rules  for:  application  definition  TEST-2X2-BIIARY-ARRAY-MULTIPLIER 
AO  Al  BO  Bl  AIDl  AID2  AID3  AID4  HAl  HA2  CO  Cl  C2  C3 
BIIARY-ARRAY-TEST  BIIARY-ARRAY  - 
2)  CHECK-SENAITICS 
.>  (ar  2) 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  C3 

in  subsystem  BIIARY-ARRAY 
Choose  the  export  item  (subsystem  and  component) 
that  you  wish  to  be  the  source  of  this  data: 

1>  subsystem  "BIIARY-ARRAY"  component  "AO"  name  "OUTl" 

2>  subsystem  "BIIARY-ARRAY"  component  "Al"  name  "OUTl" 

3>  subsystem  "BIIARY-ARRAY"  component  "BO"  name  "OUTl" 

4>  subsystem  "BIIARY-ARRAY"  component  "Bl"  name  "OUTl" 

6>  subsystem  "BIIARY-ARRAY"  component  "AIDl"  name  "OUTl" 

6>  subsystem  "BIIARY-ARRAY"  component  "AID2"  name  "OUTl" 

7>  subsystem  "BIIARY-ARRAY"  component  "AID3"  name  "OUTl" 

8>  subsystem  "BIIARY-ARRAY"  component  "AID4"  name  "OUTl" 

9>  subsystem  "BIIARY-ARRAY"  component  "HAl"  name  "S" 

10>  subsystem  "BIIARY-ARRAY"  component  "HAl"  name  "C" 

11>  subsystem  "BIIARY-ARRAY"  component  "HA2"  name  "S" 

12>  subsystem  "BIIARY-ARRAY"  component  "HA2"  name  "C" 

13>  Specific  source  not  required;  use  arbitrary  one 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
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12 


More  than  one  export  can  provide  the  data  for  III 

ahich  is  used  by  object  C2 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  sant  to  use 
11 

More  than  one  export  can  provide  the  data  for  III 

Bhich  is  used  by  object  Cl 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  sant  to  use 

9 

More  than  one  export  can  provide  the  data  for  III 

Bhich  is  used  by  object  CO 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  Bant  to  use 

5 

More  than  one  export  can  provide  the  data  for  II2 

Bhich  is  used  by  object  HA2 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  Bant  to  use 
8 

More  than  one  export  can  provide  the  data  for  III 

Bhich  is  used  by  object  BA2 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  Bant  to  use 

10 

More  than  one  export  can  provide  the  data  for  II2 

Bhich  is  used  by  object  HAl 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  Bant  to  use 

6 

More  them  one  export  can  provide  the  data  for  III 

Bhich  is  used  by  object  HAl 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  Bant  to  use 
7 

More  than  one  export  can  provide  the  data  for  II2 

Bhich  is  used  by  object  AID4 

in  subsystem  BIIARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  Bant  to  use 
4 

More  than  one  export  can  provide  the  data  for  III 
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Hhich  is  used  by  object  AVD4 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  sant  to  use 
2 

More  than  one  export  can  provide  the  data  for  IN2 

which  is  used  by  object  AIDS 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  wemt  to  use 

3 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  AND3 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
2 

More  than  one  export  can  provide  the  data  for  IR2 

which  is  used  by  object  AND2 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  want  to  use 

4 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  AND2 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
1 

More  them  one  export  can  provide  the  data  for  IN2 

which  is  used  by  object  ANDl 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  INI 

which  is  used  by  object  ANDl 

in  subsystem  BINARY-ARRAY 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
1 

Rule  successfully  applied. 

application  definition  TEST-2X2-BINARY-ARRAY-MULTIPLIER 
AO  A1  BO  B1  ANDl  AND2  AND3  AND4  HAl  HA2  CO  Cl  C2  C3 
BINARY-ARRAY-TEST  BINARY-ARRAY 
•>  (rs) 

-  Rules  for:  application  definition  TEST-2X2-BINARY-ARRAY-MULTIPLIER 
AO  A1  BO  B1  ANDl  AND2  AND3  AND4  HAl  HA2  CO  Cl  C2  C3 
BINARY-ARRAY-TEST  BINARY-ARRAY  - 

1)  DO-EXECUTE 

2)  CHECK-SEMANTICS 
.>  (ar  1) 
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LED  CO  =  01 
LED  Cl  =  OFF 
LED  C2  =  OFF 
LED  C3  =  01 


Rule  successfully  applied. 

application  definition  TEST-2X2-BIIARY-ARRAY-MULTIPLIER 
AO  A1  BO  B1  AHDl  AHD2  A1D3  AI04  HAl  HA2  CO  Cl  C2  C3 
BIIARY-ARRAY-TEST  BIIARY-ARRAY 
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C.5  Universal  Shift  Register 


This  test  case  builds  a  universal  4-bit  shift  register  which,  depending  on  the  value  of 
the  select  lines,  can  load  4  bits  into  the  register,  shift  the  contents  of  the  register  to  the 
left,  shift  the  contents  to  the  right  or  do  nothing.  Often  these  registers  are  constructed 
using  D  flipflops.  However,  since  the  validating  domain  contains  no  D  flipflops,  JK  flipflops 
were  substituted.  Table  C.2  summarizes  the  expected  action  for  various  select  line  values. 

Table  C.2.  Universal  Shift  Register  Controls 


Si 

^0 

Function 

0 

0 

shift  contents  right 

1 

0 

shift  contents  left 

0 

1 

load  input  into  register 

1 

1 

do  nothing 

C.5.1  Circuit  Diagram  See  Figure  C.6  (8:287). 


C.5. 2  Application  Specification 
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application  definition  tast-nniversal-shift-register 


snitch  diO  position:  off 
snitch  dil  position:  on 
snitch  di2  position:  off 
snitch  di3  position:  on 


snitch  sO  position:  on 
snitch  si  position:  off 

snitch  left-in  position:  off 
snitch  right-in  position:  off 
snitch  clock  position:  on 


led  doO 
led  dol 
led  do2 
led  do3 


mux  mnzO 
nuz  mnzl 
■nx  max2 
mux  nux3 


not-gate  not-jO 
not-gate  nct-jl 
not-gate  not-j2 
not-gate  not-j3 

jk-flip-flop  jkO  state  off 
jk-flip-flop  jkl  state  off 
jk-flip-flop  jk2  state  off 
jk-flip-flop  jk3  state  off 


application  nniversal-shift-register 
controls :  universal-shif t-reg 
update  procedure: 

update  uninersal-sbift-reg 
update  universal-shift-reg 

subsystem  universal-shift-reg  is 
controls:  diO,  dil,  di2,  di3,  sC, 
doO,  dol,  do2,  do3, 
muxO,  muxl,  mux2,  mux3, 
jkO,  jkl,  jk2,  jk3, 
not-jO,  not-jl,  not-j2, 
update  procedure: 
update  diO 
update  dil 
update  di2 
update  di3 


is 


si,  left-in,  right-in,  clock. 


not-j3 
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update  right-in 
update  left-in 
update  clock 
update  sO 
update  si 

if  sl.outl  and  not  sO.outl  then 
update  biux3 
update  not-j3 
update  jk3 
update  muz2 
update  not-j2 
update  jk2 
update  muxl 
update  not-jl 
update  jkl 
update  muxO 
update  not-jO 
update  jkO 
update  do3 
update  do2 
update  dol 
update  doO 
else 

update  auxO 
update  not-jO 
update  jkO 
update  Buxl 
update  not-jl 
update  jkl 
update  muz2 
update  not-j2 
update  jk2 
update  muz3 
update  not-j3 
update  jk3 
update  do3 
update  do2 
update  dol 
update  doO 
end  if 

setstate  sO  (position,  off) 
setstate  si  (position,  off) 


C.5.3  System/User  Dialogue 

.>  (#>  application  definition  test-universal-shift-register) 
application  definition  TEST-UIIVERSAL-SHIFT-REGISTER 

DIO  Dll  DI2  DI3  SO  SI  LEFT-II  RIGHT-II  CLOCK  DOO  DOl  D02 
DOS  MUXO  MUXl  MUX2  MUXS  MOT-JO  lOT-Jl  I0T-J2  I0T-J3  JKO  JKl 
JK2  JK3  UIIVERSAL-SHIFT-REGISTER  UIIVERSAL-SHIFT-REG 
.>  (rs) 
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-  Rules  lor:  application  definition  TEST-UIIVERSiL-SHIFT-REGISTER 
010  011  012  013  SO  SI  LEFT-II  RIGHT-II  CLOCK  000  001  002 
003  MOIO  mill  MUX2  1IUX3  lOT-JO  lOT-Jl  I0T-J2  101-13  JKO  JKl 
JK2  JK3  OIIVERSiL-SHIFT-REGISTER  UIIVERSAL-SHIFT-REG  - 
2)  CHECK-SENAITICS 
.>  (ar  2) 

There  is  more  than  one  possibility  for  data  with  name  OUTl 

Choose  the  data  you  uould  like  to  use  for  evaluating  the  conditional 
1>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  I0T-J3:  name  =  OUTl 

2>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  I0T-J2:  name  =  OUTl 

3>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  lOT-Jl:  name  =  OUTl 

4>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  lOT-JO:  name  =  OUTl 

5>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  NUX3:  name  =  OUTl 

6>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  IIUX2:  name  =  OUTl 

7>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  MUXl:  name  =  OUTl 

8>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  HUXO:  name  =  OUTl 

9>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  CLOCK:  name  =  OUTl 

10>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  RIGHT-II:  name  =  OUTl 

11>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  LEFT-II:  name  »  OUTl 

12>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  SI:  name  =  OUTl 

13>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  SO:  name  ==  OUTl 

14>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  DI3:  name  =  OUTl 

15>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  DI2:  name  =  OUTl 

16>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  Dll:  name  =  OUTl 

17>  In  export  area  of  subsystem  UIIVERSAL-SHIFT-REG: 
producer  =  DIO:  name  =  OUTl 
12 

More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  I0T-J3 

in  subsystem  UIIVERSAL-SHIFT-REG 
Choose  the  export  item  (subsystem  and  component) 
that  you  wish  to  be  the  source  of  this  data: 

1>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "DIO"  name  "OUTl" 
2>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "Dll"  name  "OUTl" 
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3>  subsystem  "UlIVERSAL-SHIFT-REG"  component  "DI2“  nime  "OOTl" 

4>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "DI3"  name  "OOTl" 

6>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "SO"  name  "OUT!" 

6>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "SI"  name  "OUTl" 

7>  subsystem  "OIIVERSAL-SHIFT-REG"  component  "LEFT-II"  name  "OUTl" 
8>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "RIGHT-II"  name  "OUTl" 
9>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "CLOCK"  name  "OUTl" 

10>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "MUXO"  name  "OUTl" 

11>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "MUXl"  name  "OUTl" 

12>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "MUX2"  name  "OUTl" 

13>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "MUXS"  name  "OUTl" 

14>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JKO"  name  "Q" 

15>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JKO"  name  "Q-BAR" 

16>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JKl"  name  "Q" 

17>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JKl"  name  "Q-BAR" 

18>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JK2"  name  "Q" 

19>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JK2"  name  "Q-BAR" 
20>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JK3"  name  "Q" 

21>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "JK3"  name  "Q-BAR" 
22>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "lOT-JO"  name  "OUTl" 
23>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "lOT-Jl"  name  "OUTl" 
24>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "I0T-J2"  name  "OUTl" 
25>  subsystem  "UIIVERSAL-SHIFT-REG"  component  "I0T-J3"  name  "OUTl" 
26>  Specific  source  not  required;  use  arbitrary  one 
Enter  the  number  corresponding  to  the  source  you  want  to  use 


More  than  one  export  can  provide  the  data  for  III 

uhich  is  used  by  object  I0T-J2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
12 

More  than  one  export  can  provide  the  data  for  III 

vhich  is  used  by  object  lOT-Jl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
11 

More  than  one  export  cw  provide  the  data  for  III 

vhich  is  used  by  object  lOT-JO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 


More  than  one  export  can  provide  the  data  for  CLK 

vhich  is  used  by  object  JK3 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
9 


C-43 


More  than  one  export  can  provide  the  data  for  K 

which  is  used  by  object  JK3 

in  subsystem  UlIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
2S 

More  thaui  one  export  cem  provide  the  data  lor  J 

which  is  used  by  object  JK3 

in  subsystem  UBIVERSAL-SEIFT-REG 
Enter  the  number  corresponding  to  the  source  you  waoit  to  use 
13 

More  than  one  export  can  provide  the  data  for  CLK 

which  is  used  by  object  JK2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
9 

More  than  one  export  can  provide  the  data  for  K 

which  is  used  by  object  JK2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  weoit  to  use 
24 

More  than  one  export  can  provide  the  data  for  J 

which  is  used  by  object  JK2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
12 

More  than  one  export  can  provide  the  data  for  CLK 

which  is  used  by  object  JKl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
9 

More  than  one  export  can  provide  the  data  for  K 

which  is  used  by  object  JKl 

in  subsystem  UIIVERSAL-SHIFT-REG 

Enter  the  number  corresponding  to  the  source  you  want  to  use 
23 

More  than  one  export  can  provide  the  data  for  J 

which  is  used  by  object  JKl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
11 

More  than  one  export  can  provide  the  data  for  CLK 

which  is  used  by  object  JKO 


in  subsystem  UllVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  uant  to  use 

9 

More  than  one  export  can  provide  the  data  for  K 

vhich  is  used  by  object  JKO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  ucuit  to  use 
22 

More  than  one  export  can  provide  the  data  lor  J 

Bhich  is  used  by  object  JKO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  sant  to  use 

10 

More  than  one  export  can  provide  the  data  lor  SI 

which  is  used  by  object  NUX3 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  lor  SO 

which  is  used  by  object  MUXS 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  lor  IH3 

which  is  used  by  object  MUXS 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
20 

More  than  one  export  can  provide  the  data  lor  II2 

which  is  used  by  object  MUXS 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
18 

More  than  one  export  can  provide  the  data  lor  III 

which  is  used  by  object  MUXS 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
4 

More  than  one  export  can  provide  the  data  lor  IIO 

which  is  used  by  object  MUXS 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
7 
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More  than  one  export  can  provide  the  data  for  SI 

which  is  used  by  object  MUX2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  for  SO 

which  is  used  by  object  MUX2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 

5 

More  than  one  export  can  provide  the  data  for  113 

which  is  used  by  object  NUX2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
18 

More  than  one  export  can  provide  the  data  for  II2 

which  is  used  by  object  MUX2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
16 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  MUX2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
3 

More  than  one  export  can  provide  the  data  for  IIO 

which  is  used  by  object  MUX2 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
20 

More  than  one  export  can  provide  the  data  for  SI 

which  is  used  by  object  MUXl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 

6 

More  than  one  export  can  provide  the  data  for  SO 

which  is  used  by  object  MUXl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  for  113 

which  is  used  by  object  MUXl 
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in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  sauit  to  use 
16 

More  than  one  export  can  provide  the  data  lor  IH2 

nhich  is  used  by  object  MUXl 

in  subsystem  UIIVERSAL-SHIFT-REG 
CEnter  the  number  corresponding  to  the  source  you  sant  to  use 
14 

More  than  one  export  can  provide  the  data  for  III 

nhich  is  used  by  object  MUXl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  nvunber  corresponding  to  the  source  you  uant  to  use 
2 

More  than  one  export  can  provide  the  data  for  IIO 

Bhich  is  used  by  object  MUXl 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  wsmt  to  use 
18 

More  than  one  export  can  provide  the  data  for  SI 

which  is  used  by  object  MUXO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  for  SO 

which  is  used  by  object  MUXO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
6 

More  than  one  export  can  provide  the  data  for  113 

which  is  used  by  object  MUXO 

in  subsystem  UIIVERSAL-SHIFT-Ri.'" 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
14 

More  than  one  export  can  provide  the  data  for  112 

which  is  used  by  object  MUXO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
8 

More  than  one  export  can  provide  the  data  for  III 

which  is  used  by  object  MUXO 

in  subsystem  UIIVERSAL-SHIFT-REG 
Enter  the  niuaber  corresponding  to  the  source  you  want  to  use 
1 
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More  than  one  export  can  provide  the  data  for  IHO 

vhich  is  used  by  object  NUXO 

in  subsystem  UHIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  uant  to  use 
16 

More  than  one  export  can  provide  the  data  for  IHl 

which  is  used  by  object  DOS 

in  subsystem  UBIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
20 

More  than  one  export  can  provide  the  data  for  IHl 

which  is  used  by  object  D02 

in  subsystem  UHIVERSAL-SHIFT-REG 
Enter  the  niunber  corresponding  to  the  source  you  weuit  to  use 
18 

More  than  one  export  can  provide  the  data  for  IHl 

which  is  used  by  object  DOl 

in  subsystem  UHIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
16 

More  than  one  export  can  provide  the  data  for  IHl 

which  is  used  by  object  DOO 

in  subsystem  UHIVERSAL-SHIFT-REG 
Enter  the  number  corresponding  to  the  source  you  want  to  use 
14 

Rule  successfully  applied. 

application  definition  TEST-UHIVERSAL-SHIFT-REGISTER 

DIO  Dll  DI2  DI3  SO  SI  LEFT-IH  RIGHT-IH  CLOCK  DOO  DOl  D02 
DOS  MUXO  MUXl  MUX2  MUXS  HOT- JO  HOT-Jl  H0T-J2  HOT-JS  JKO  JKl 
JK2  JKS  UHIVERSAL-SHIFT-REGISTER  UHIVERSAL-SHIFT-REG 
•>  (rs) 

-  Rules  for:  application  definition  TEST-UHIVERSAL-SHIFT-REGISTER 
DIO  Dll  DI2  DIS  SO  SI  LEFT-IH  RIGHT-IH  CLOCK  DOO  DOl  D02 
DOS  MUXO  MUXl  MUX2  MUXS  HOT-JO  HOT-Jl  H0T-J2  HOT-JS  JKO  JKl 
JK2  JKS  UHIVERSAL-SHIFT-REGISTER  UHIVEESAL-SHIFT-REG  - 

1)  DO-EXECUTE 

2)  CHECK-SEMAHTICS 
•>  (ar  1) 

LED  DOS  =  OH 
LED  D02  =  OFF 
LEO  DOl  =  OH 
LED  DOO  =  OFF 
LED  DOS  =  OFF 
LED  002  =  OH 
LED  DOl  =  OFF 
LEO  000  =  OH 
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Rule  successfully  applied. 

application  definition  TEST-UIIVERSAL-SHIFT-REGISTER 

DIO  Dll  DI2  DI3  SO  SI  LEFT-II  RIGHT-IR  CLOCK  DOO  DOl  D02 
DOS  MUXO  MUXl  MUX2  MUXS  HOT- JO  lOT-Jl  H0T-J2  HOT-JS  JKO  JKl 
JK2  JKS  UHIVERSAL-SHIFT-REGISTER  UHIVERSAL-SHIFT-REG 
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Appendix  D.  Code 


This  appendix  contains  the  REFINE  source  code  for  the  Preprocessing,  Semantic 
Check  and  Execute  portions  of  Architect,  the  application  composer  described  in  Section  4.1. 
Each  section  corresponds  to  an  individual  source  code  file. 

D.l  Globals  Definitions 

! !  in-package ("RU") 

!!  in-granunarC ’user) 

«l  I 

File  name:  globals. re 

Description:  Contains  all  the  global  constants  and  variables. 

II* 

constant  Saved-Suiliz  :  string  =  "-SAVED” 
constant  Generics-Path  :  string  =  "../generics/" 
constant  Applic-Path  :  string  =  "../applies/" 
constant  Object -Path  :  string  =  "../objs/" 
constant  separator  :  char  =  #\. 
var  Fatal-Error  :  boolean  =  f<Qse 
var  Changes-Nade  :  boolean  =  false 
var  Semantic-Checks-Performed  :  boolean  =  false 

D.2  REFINE  Domain  Model 

! !  in-package ("RD") 

!!  in-grammar (’user) 

«l  I 

File  name:  dm-ocu.re 
Description: 
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This  version  includes  only  the  domain- independent  dm 
data.  Domain-specific  domain  knovledge  is  included  in  the 
technology  base  in  the  file  for  the  corresponding  object 
class . 

II# 

y.  OBJECT  CLASSES: 

var  World-Obj  :  object-class  subtype-of  user-Object 

var  Spec-Obj  :  object-class  subtype-ol  Horld-Obj 

%  A  high-level  object  that  ties  together  all  of  the  parts  of  an 
y.  application  definition 

var  Spec-Part-Obj  :  object-class  subtype-of  World-Obj 

%  Spec-Parts  describe  all  of  the  senetences  used  by  the  application 
X  specieilist  to  build  an  application  definition 

var  Incomplete-Obj  :  object-class  subtype-of  Spec-Part-Obj 

var  Generic-Inst  :  object-class  subt3fpe-of  Spec-Part-Obj 

var  Load-Obj  :  object-class  subtype-of  Spec-Part-Obj 

var  Component-Obj  :  object-class  subtype-of  Spec-Part-Obj 

y.  Component-Obj  ’  s  are  all  the  parts  of  a  final  definition 

var  Application-Obj  :  object-class  subtype-of  Component-Obj 

var  Subsystem-Obj  :  object-class  subtype-of  Component-Obj 

var  Primitive-Obj  :  object-class  subtype-of  Component-Obj 


var  Statement-Obj 
var  If-Stmt-Obj 
var  Uhile-Stmt-Obj 
var  Call-Obj 

var  Opdate-Call-Obj 
var  Create-Call-Obj 
var  SetFunction-Call-Obj 
var  SetState-Call-Obj 
var  Destroy-Call-Obj 
var  Initialize-Call-Obj 
var  Stabilize-Call-Obj 
var  Conf igure-Call-Obj 


object-class  subtype-of  World-Obj 
object-class  subtype-of  Statement-Obj 
object-class  subt]fpe-of  Statement-Obj 
object-class  subtype-of  Statement-Obj 
object-class  subtype-of  Call-Obj 
object-class  subtype-of  Call-Obj 
object-class  subtype-of  C2Q.l-0bj 
object-class  subtype-of  Call-Obj 
object-class  subtype-of  Call-Obj 
object-class  subtype-of  czdl-obj 
object-class  subtype-of  c2Q.l-obj 
object-class  subtype-of  call-obj 


var  Import-Export-Obj 
var  Import-Obj 
var  Export-Obj 
var  lame-Value-Obj 
var  Source-Obj 


:  object-class  subtype-of  World-Obj 
:  object-class  subtype-of  Import-Export-Obj 
:  object-class  subtype-of  Import-Export-Obj 
;  object -class  subtype-of  World-Obj 
:  object-class  subtype-of  World-Obj 


var  Generic-Obj 


:  object-class  subtype-of  World-Obj 


m  ATTRIBUTES: 


%  Spec-Obj : 

var  Spec-Parts  :  map (Spec-Obj ,  aeq(Spec-Part-Obj)) 
computed-using 

Spec-Parts (x)  =  □ 

%  Incomplete-Obj : 

var  Obj-Type  :  map(Incomplete-Obj ,  symbol)  =  {1  1} 

y,  Generic-Inst : 

var  Generic-To-Be-Used  :  map(Generic-Iiist,  symbol)  =  {|  |> 
var  Generic-Peurameters  :  map(6eiieric-Inst.  seq(aiiy-type)) 
computed-using 

Generic-Parameters (z)  =  □ 

%  Load-Obj : 

var  Ob j ect-To-Load  :  map(Load-Obj ,  symbol)  =  {|  |} 


y.  Application-Obj : 

var  Application-Components  :  map(Application-Obj ,  seq(symbol)) 
computed-using 

Application-Components(z)  =  □ 

var  Application-update  :  map(Application-Obj ,  seq(Statement-Obj)) 

computed-using 

Application-update(z)  =  □ 

y,  Subsystem-Obj : 

var  Controllees  :  map (Subsystem-Obj,  seq(symbol)) 

computed-using 

controllees (x)  =  □ 


y.%  changed  seq  to  set  in  import-Area  and  Export-Area  . . . 
var  Import-Area  :  map(Subsystem-Obj ,  set(Import-Obj)) 

comput  ed-us ing 
Import-Area(x)  =  {} 

vau:  Export-Area  :  map(Subsystem-Obj ,  set(Ezport-Obj)) 

comput  ed-us ing 

Export-Area(x)  =  O 


var  Update  :  map(Subsystem-Obj ,  seq(Statement-Obj)) 

comput  ed-us ing 
Update(x)  =  □ 

var  Initialize  :  map(sub8y8tem-obj ,  seq(name-v2aue-obj)) 

comput  ed-us ing 

Initialize(x)  =  □ 


%  Statements: 
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%  Il-Stmt-Obj 

var  Il-Cond 
var  Then-Stmts 
computed-tts ing 

Then-Stmts (z)  =  □ 
var  Else-Stmts 
computed-nsing 

Else-Stmts (x)  =  [] 

y,  Hhile-Stmt-Obj : 

var  While-cond 
var  Vhile-stmts 
computed-using 

Vhile-stmts (z)  =  □ 


:  map(Il-stmt-Obj ,  Expression)  =  {1  |} 

:  map(Ii-stmt-Obj,  seq(Statement-Obj)) 


:  map(If-stmt-Obj ,  seq(Statement-Obj)) 


:  map(While-stmt-Obj ,  expression)  =  -Cl  1} 
:  map(Whilo-stmt-Obj ,  seq(Statement-Obj)) 


%  Call-Obj: 

var  operand  :  map ( Call-Obj ,  symbol)  =  {1  l> 

%  Create-Call-Obj ; 

var  object-type  :  map(create-Call-Obj,  symbol)  =  {ll> 


%  SetFnnction-Call-Obj : 

var  fnnction-name  :  map(SetFunction-Call-Obj ,  symbol)  =  -(11} 

var  coeflicients  :  map (SetFnnction-Call-Obj ,  set(name-valne-Obj)) 

compnted-using 

coeTficients(x)  =  O 


%  SetState-Call-Obj : 

var  state-chuges  :  map(SetState-Call-Obj ,  set(name-valne-Obj)) 

compnted-us ing 

state-changes (x)  =  {} 


%  Import-Obj ; 
var  iiq>ort-name 

:  map (Import-Obj, 

symbol) 

=  (11} 

var  import-category 

:  map ( Import-Obj , 

symbol) 

=  (11} 

var  import-type-data 

:  map(Import-Obj, 

symbol) 

=  {ll> 

var  consumer 

:  map ( Import-Obj , 

symbol) 

=  (11} 

var  Source 

:  map(Import-Obj , 

set (Source-Ob j ) ) 

compnt  ed-us ing 

Source(x)  =  O 

X  Export-Obj: 
var  export-name 

:  map ( Export-Obj . 

symbol) 

=  (11} 

var  export-category 

:  map (Export-Obj , 

symbol) 

=  (11} 

var  export-type-data 

:  map (Export-Obj , 

symbol) 

=  (11} 

var  value 

:  map(Export-Obj , 

any-type) 

=  (11} 

var  producer 

;  map (Export-Obj . 

symbol) 

=  (11} 

D-4 


%  laae-Value-Ob j : 
var  laiie-v2Que-Iame 
var  lane-value-value 


:  map(Iame-value-Obj,  sjnnbol)  =  {||> 

:  map ( lane- value-Ob j ,  any-type)  =  {11} 


%  Source-Obj : 
var  Source-Subsystem 
var  Source-Object 
var  Source-l2uae 


:  map (Source-Obj .  symbol)  =  { 1 1 } 
:  map ( Source-Obj ,  symbol)  =  {||} 
:  map ( Source-Obj ,  symbol)  =  {11} 


%  Generic-Obj : 

var  Obj-Instance  :  map(Generic-Obj ,  S3nnbol)  =  {1 

var  Placeholder- IDs  :  map(Generic-Obj,  seq(any-type)) 

computed-us ing 

Placeholder- IDs (z)  =  □ 


1} 


var  Placeholder-Type  :  map ( Generic-Obj ,  seq(symbol)) 
computed-using 
Placeholder-Type (x)  =  □ 


X - 

i.  Code  lor  Boolean-expressions 
var  Expression  :  object-class  subtype-ol  Uorld-Obj 


var  Literal-Expression 


object-class  subtype-of 


expression 


var  Identifier 
var  Boolean-Literal 
var  True-Literal 
var  False-Literal 
var  lumber-Literal 
var  Integer-Literal 
var  Real-Literal 
var  String-Literal 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


Literal-Expression 

Literal-Expression 

Boolean-LitereG. 

Boolean-Literal 

Literal-Expression 

lumber-Literal 

lumber-Literal 

Literal-Expression 


var  Unary-Expression 
veu:  lot-Exp 
var  abs-exp 
var  negate-ezp 
var  positive-exp 


object-class  subtype-of  Expression 
object-class  subtype-of  Unary-Expression 
object-class  subt3rpe-of  unary-expression 
object-class  subtype-of  unary-expression 
object-class  subtype-of  un^a^y-expression 


vu  Binary-Expression 
var  Or-Exp 
var  And-Exp 
var  Equal-Exp 
var  lot-Equal-Exp 
var  LT-Exp 
var  LTE-Exp 
var  GT-Exp 
var  GTE-Exp 


object-class  subtype-of  Expression 
object-class  subtype-of  Binary-Expression 
object-class  subt3rpe-of  Binary-Expression 
object-class  subtype-of  Binary-Expression 
object-class  subtype-of  Bin^u^y-Expression 
object-class  subtype-of  Binary-Expression 
object-class  subtype-of  Binary-Expression 
object-class  subtype-of  Binary-Expression 
object-class  subtype-of  Binary-Expression 
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var  add-exp 

var  subtract-ezp 

v!u:  multiply-exp 

var  divide-exp 

var  mod- exp 

var  exponential-exp 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


subtype-of  Binary-Expression 
subtjrpe-ol  Binary-Expression 
snbtype-of  Binary-Expression 
snbtype-ol  Binary-Expression 
subtype-of  Binary-Expression 
snbt]^e-ol  Binary-Expression 


Attributes  for  expressions: 

var  Id-lame  :  mapCldentif ier,  symbol)  =  {|  1} 

var  Id-Source  :  map (Identifier,  import-export-obj )  =  {1  1} 


var  Int -value 
var  Re2Q.-value 
var  Boolean-value 
var  String-value 


:  mapClnteger-Literal,  integer)  =  {|  |} 
:  map  (Real-Lit  ers^.,  real)  =  {|  |} 

:  map(Boolean-Literal.  boolean)  =  {|  1} 
:  map (String-Literal,  string)  =  {I  1} 


var  Argumentl  :  map(Binary-Expression,  Expression)  =  -Cl  1} 

var  Argument2  :  map(Binary-Expression,  Expression)  =  {|  1} 

var  Argument  :  map(Unary-Expression,  Expression)  =  -Cl  1} 

%%  Tree  Attributes  For  Expressions 
Form  Expression-Attrs 

define-tree-attributes( ’Binary-Expression,  -(’Argumentl,  ’Argument2}) ; 
def ine-tree-attributas( ’Unary-Expression,  {’Argument}) 


Form  Define- AST 

def ine-tree-attributes( ’Wbile-Stmt-Obj ,  {’Mbile-Cond,  ’While-Stmts}) ; 
define-tree-attributes( ’If-Stmt-Obj ,  {’If-Cond,  ’Then-Stmts,  ’Else-Stmts}) ; 
def ine-tree-attributes( ’Call-Obj ,  {’Operand}) ; 
def ine-tree-attributes( ’SetFunction-Call-Obj ,  { ’Function-lame , 

’Coefficients}) ; 

def ine-tree-attributes( ’SetState-Call-Obj ,  {’state-changes}) ; 
def ine-tree-attributes( ’ Application-Obj ,  {’Application-Components , 

’Application-Update}) ; 
def ine-tree-attribute8( ’Subsystem-Obj , 

{ ’ Controllees ,  ’Update,  ’Initialize,  ’Export-Area,  ’Import-Area}); 
def ine-tree-attributes ( ’ Spec-Ob j ,  { ’ Spec-Parts}) ; 

def ine-tree-attributes ( ’ Import-Ob j ,  { ’ Import-lame ,  ’ Import-Cat egory , 

'Import -Type-Data,  ’Source,  ’Consumer}); 
def ine-tree-attributes ( ’ Export-Ob j ,  { ’ Export -lame ,  ’ Export-Category , 

’Export-Type-Data,  ’ViQue,  ’Producer}); 
def ine-tree-attribute8( ’6eneric-0bj ,  {’Obj-Instance,  ’Placeholder-Ids}) 

form  Make-lames-Unique 
unique-names-cla8s( ’Spec-Ob j ,  true); 
unique-names- class ( ’ Application-Obj ,  true) ; 
unique-name8-cla8s( ’Subsystem-Obj ,  true) ; 
unique-names-class ( ’Generic-Obj ,  true) ; 
unique-name8-cla88( ’Generic-Inst ,  true) ; 
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imique-names-classC ’Load-Obj ,  true) ; 
unique-names-classC  *Incoiiq)lete-Obj ,  true) 


D.3  OCU  Grammar 


!!  in-package ("RU") 

!!  in-gramnarC 'synt^uc) 

«ll 

File  name:  gram-ocu.re 

Description:  The  OCU  grammar  -  eJ.!  of  the  domain- independent  productions,  most  of  uhich 
describe  the  OCU  model 

lOTE:  If  you  chsmge  this  file,  you  must  ed.so  recompile  the  domain-specific  grammar. 

If  no  changes  are  made  to  that  grammar,  erase  its  .fasl4  file  to  make  sure  it 
recompiles.  Otherwise,  you  won't  see  the  changes  made  to  the  OCU  grammar. 

(See  the  DIALECT  User’s  guide  about  grammar  inheritance) 

Rules: 

lone 

Functions : 
lone 

II# 


grammar  OCU 
no-pattems 

start-classes  Spec-Obj ,  Subsystem-obj ,  Incomplete-obj ,  Load-Obj ,  Generic-Obj 
file-classes  Spec-Obj,  Subsystem-obj,  Incomplete-obj,  Load-Obj,  Generic-Obj 
productions 

Spec-Obj  ::=  ["application"  "definition"  name  {Spec-Parts  +  ""}  ] 

builds  Spec-Obj , 

Application-Obj  :  •.=  ["application"  name  "is" 

"controls:"  application-components  ♦  "," 

"update  procedure:" 

application-update  *  ""]  builds  Application-Obj, 

Subsystem-Obj  ::=  ["subsystem"  name  "is" 

"controls:"  Controllees  ♦  "," 

{["imports:"  Import-Area  *  ""]} 

{["exports:"  Export-Area  *  ""]} 

{["initialize  procedure:" 
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builds  Subsystem-Obj , 


Import-Ob j  : : = 

Export-Ob j  : : = 

Source-Ob j  : : = 

Generic-Inst  :;= 

Incomplete-Obj  ::= 
Load-Ob j  : : = 

If-Stmt-Qb j  ; : = 

Hbile-Strat-Obj  : : = 

Updat«-Call-Ob j  : :  = 
Create-Call-Ob j  : :  = 
SetFunct ion-CeO-l-Ob j 

SetState-Call-Obj 

Destroy-Call-Obj 
Initialixe-Call-Obj 
Conf igur e-Call-Ob j 
Stabilize-Call-Obj 
lane-Valua-Obj 

Ganeric-Ob j  : : = 


initiailize  * 

"update  procedure:" 
update  ♦  ""  ] 

[import-name  import-category  import-type-data 
consumer  "("  [source  ♦  ""]  ")"]  builds  Import-Ob j , 

[export-name  export-category  export-type-data 
value  producer]  builds  Export-Obj , 

[Source-lame  Source-Subsystem  Source-Object] 
builds  Source-Ob j, 

["generic"  name  "is"  "new"  Generic-To-Be-Used 
Generic-Parameters  *  ","]  builds  Generic-Inst, 

["object"  obj-type  name]  builds  Incomplete-obj , 

["load"  Object-To-Load]  builds  Load-Obj , 

["if"  il-cond  "then"  Then-Stmts  +  "" 

{["else"  Else-Stmts  +  ""]> 

"end"  "if"  ]  builds  If-Stmt-Obj , 

!"while"  while-cond  "loop" 

While-Stmts  * 

"end"  "while"  ]  builds  While-Stmt-Obj , 

["update"  operand]  builds  Update-Call-Obj , 

["create"  operand  object-type]  builds  Create-Call-Obj , 

::=  ["setf unction"  oper2uid  function-neune 

Coefficients  ♦  ""]  builds  SetFunction-Call-Obj , 

::=  ["setstate"  operand 

State-Changes  *  ""]  builds  SetState-Czdl-Obj , 

: : =  ["destroy"  operand]  builds  Destroy-C2j.l-0bj , 

["initialize"  operand]  builds  Initi€ilize-Call-Obj , 

["configure"  operand]  builds  Conf igur e-Call-Obj , 

["stabilize"  operand]  builds  Stabilize-Call-Obj, 

: : =  [" ( "  name-value-name  " , " 

name-value-veQue  ")"]  builds  lame-Value-Obj , 


!"generic-obj"  name  Ob j -Instance 


"ids:"  {Placeholder-IDs  +  ","} 

"types:"  {Placeholder- Type  +  builds  Generic-Obj, 

And-Exp  ::=  [argument!  "and"  argUBent2]  builds  And-Exp, 

Or-Exp  ::=  [argument!  "or"  argument2]  builds  or-Exp, 

Equal-Exp  ::=  [argument!  "="  argument2]  builds  Equal-Exp, 

lot-Equal-Exp  ::=  [argument!  "/="  argufflent2]  builds  Hot-Equal-Exp, 

LT-Exp  ::=  [argtunent!  "<"  argument2]  builds  LT-Exp, 

LTE-Exp  ::=  [argument!  "<="  argument2]  builds  LTE-Exp, 

GT-Exp  : :=  [argument!  '*>"  argument23  builds  GT-Exp, 

GTE-Exp  ::=  [argument!  ">="  argument2]  builds  GTE-Exp, 

Add-Exp  ::=  [argument!  argument2]  builds  Add-Exp, 

Subtract-Exp  ::=  [argument!  argument2]  builds  Subtract-Exp, 

Nultiply-Exp  ::=  [argument!  "e"  argument2]  builds  Multiply-Exp, 

Divide-Exp  ::=  [argument!  "/“  argument2]  builds  Divide-Exp, 

Mod-Exp  ::=  [argument!  "mod"  argument2]  builds  Mod-Exp, 

Exponential-Exp  ::=  [argviment!  "**"  argument2]  builds  Exponential-Exp, 

Abs-Exp  ::=  ["abs"  argvunent]  builds  Abs-Exp, 

lot-Exp  ::=  ["not"  argument]  builds  Hot-Exp, 

Hegate-Exp  ::=  ["-"  argument]  builds  Hegate-Exp, 

Positive-Exp  ::=  ["+"  argument]  builds  Positive-Exp, 

Identifier  ::=  [Id-Hame]  builds  Identifier, 

Integer-LiteraO.  ::=  [Int-Value]  builds  Integer-Literal, 

Real-Literal  ::=  [Real-Value]  builds  Real-Literal, 

String-Literal  ::=  [String-Value]  builds  String-Literal, 

True-Literal  ::=  ["true"]  builds  True-Literal, 

False-Literal  ::=  ["false"]  builds  False-Lit ereil 

symbol-start-chars 

"abcdef ghi jklmnopqrstuvwxyzABCDEFGHIJKLMHOPQRSTUVWXYZ . " 
symbol-cont inue-chars 

"abcdef  ghi  jklmnopqrstuvvxyzABCDEFGHIJKLMH0PQRSTUVWXYZ-0!23456789 . " 
precedence 

for  expression  brackets  "("  matching  ")" 

(same-level  "and",  "or"  associativity  left), 

(same-level  "<",  "<=",  "=",  ">=",  ">",  "/="  associativity  none), 
(same-level  associativity  left), 

(same-level"*",  "/",  "mod"  associativity  left) , 

(same-level  "not"  associativity  none) , 

(same-level  "abs"  associativity  none), 

(same-level  "♦♦"  associativity  right) 

end 
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D.4  Imports- Exports 


! !  in-package ("RU") 

!!  in-grammar (’user) 

#1  I 

File  name:  imports -exports. re 

This  file  encapsulates  the  import/ezport-related  processing  in  one  place 


I  I# 


% - 

y, - 

7,7,  PREPROCESSIIG 


%7,  Build- Import-Export-Area  —  Considered  part  of  "preprocessing".  Called  from 
7,%  semantic-checks  to  build  import/export  2u:eas.  It  sets  up  the  import  eurea 
7,7,  and  export  area  of  the  subsystem  (input  parameter,  subsystem).  It 
%%  eniimerates  over  all  the  controllees  of  the  subsystem.  If  the  controllee 
7,%  is  a  primitive  object,  it  adds  a  nev  import-obj  to  the  import-area  for 
y.X  each  member  of  the  object’s  IIPUT-DATA,  if  there  is  not  already  an 
7X  import-obj  there  with  the  same  id  (uses  import-symbols  to  keep  track). 

7X  Same  kind  of  thing  for  the  exports... 

function  build-import-export-area  (subsystem  :  subsystem-obj)  = 

(enumerate  ctrlee  over  controllees (subsystem)  do 

let  (obj  :  component-obj  = 

find-object( ’component-obj ,  ctrlee)) 

if  primitive-obj (obj)  then 

7,  Are  there  any  import  items  for  this  primitive  object 
7,  in  subsystem’s  import  area? 

7,  If  not,  added  object’s  input-data  to  import  ^u:ea. 
lot  (import-set  :  sot (import-obj)  = 

{  X  I  (x: import-obj)  import-obj (x)  A 

parent-expr(x)  =  subsystem  A 
consumer(x)  =  name(obj)}) 

(if  size (import-set)  =  0  then 

7,  Ho  imports  yet  for  this  object;  add  them 

let  (input-data  :  sot (import-obj)  = 

get-input-output-variablo(obj ,  "IHPUT-DATA")) 
eniuDerate  import  over  input-data  do 

8et-attrs( import,  ’consumer,  name(obj)); 
set-attrs( subsystem,  ’import-area. 
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import-area( subsystem)  vith  copy-term(import)) 

'U  use  copy-term  so  it  makes  a  copy  of  the  object, 
%  not  just  a  pointer  to  it 


y.  Are  there  any  export  items  for  this  primitive  object 
X  in  subsystem's  export  area? 

'!%  If  not,  add  object's  output-data  to  export  area. 

let  (export-set  :  set(export-obj)  = 

{  X  1  (x:export-obj)  export-obj (x)  A 

parent-expr(x)  =  subsystem  A 
producer(x)  =  name(obj)}) 

(if  sizo(export-set)  =  0  then 

%  lo  exports  yet  for  this  object;  add  them 
let  (output-data  :  sot (export-obj)  = 

get-input-output -variablo(obj ,  "OUTPUT-DATA") ) 
enumerate  export  over  output-data  do 

set-attrs (export,  'producer,  name(obj)); 
set-attr8( subsystem,  'export-area, 

export-area (subsystem)  sith  copy-term (export)) 

y.  use  copy-term  so  it  makes  a  copy  of  the  object, 
%  not  just  a  pointer  to  it 

) 

); 

X  low  that  me've  ensured  all  input-data  and  output-data  for 
%  all  primitive  object  controllees  are  in  import/export  area, 

%  must  remove  any  extraneous  ones  (belonged  to  primitive  objects 
%  which  are  no  longer  part  of  the  subsystem) 

let  (imports-not-used  :  8et(import-obj)  = 

•C  X  I  (x :  import-ob j )  import-obj  (x)  A 

parent-expr(x)  =  subsystem  A 
consumer(x)  'in  controllees (subsystem)}) 
(enumerate  in^ort  over  imports-not-used  do 

set-attrs (subsystem,  'import-area,  ifflport-area(subsystem)  less  import) 

); 


let  (export 8 -not -used  :  set (export-obj)  = 

•{  X  I  (x: export-obj)  export-obj (x)  A 

parent-expr(x)  =  subsystem  A 
producer(x)  'in  controllees (subsystem)}) 

(enumerate  export  over  exports-not-used  do 

set-attrs (subsystem,  'export-area,  export-araa(subsystem^  lass  export) 

) 


%• 

X- 
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yX  Determine-Sources-for-Conditionals  —  Considered  part  oi  preprocessing. 
y.%  Called  by  semantic-checks  after  the  subsystem’s  import  and  export  areas 

Vh  are  built  to  associate  each  identifier  (in  an  if/uhile  condition)  with  an 

yX  import-obj  or  ezport-obj  in  the  subsystem’s  import/export  areas. 

%%  Each  identifier  in  a  conditional  must  reference  an  import-obj  or  export-obj 
yX  in  its  subsystem’s  import  area  or  export-area  (as  there  is  no  "get-state" 
%y,  interface  in  the  OCU  model,  all  identifiers  in  conditionals  must  reference 
yXt  import/export  areas,  the  only  data  available).  This  process  is  very  like 
V/,  obtaining  the  source  for  import-objs. . . 

function  determine-sources-for-conditionals  (  subsystem  :  subsystem-obj  )  = 

let  (identifiers  :  seq  (identifier)  = 

[  i  I  (i: identifier)  identif ier(i)  k 

leaat-ancestor-of-class(i,  ’subsystem-obj)  =  subsystem]) 


enumerate  id  over  identifiers  do 

if  undefined? (id-source (id))  then  %  do  not  yet  have  any  source 
lot  (id-string  :  string  =  symbol-to-string(id-name(id))) 
if  separator  in  id-string  then  user  has  qualified  id  name 
extract-and-set-id-source(id) 
else 

get-id-source-for-conditional(id) 

else 

format(t,  "'*/,"*/,There  is  zdready  a  source  specified  for  id  's", 
id-name(id)); 

format(t,  "  in  conditional  expression'*/,") ; 

format (t,  "  in  subsystem  's'*/(", 

naffle(least-ance3tor-of-class(id,  ’subsystem-obj))) ; 

(if  import-obj (id-source (id))  then 

format(t,  "  The  source  is  the  import  item  "3'%", 
import-name ( id-source (id) ) ) ; 
format (t,  "  consumed  by  's'*/,", 

consumer ( id-source ( id) ) ) 


else 

format(t,  "  The  source  is  the  export  item  's''/(", 
export-name(id-source(id))); 
format(t,  "  produced  by  "s'*/,", 

producer ( id-source ( id) ) ) 

): 


if  lisp: :y-or-n-p("Do  you  want  to  select  a  different  source?")  then 
get-id-source-f or-condit ional ( id) 

51 - 


5j - 

Determine-Import-Sources  —  Considered  p2u:t  of  "preprocessing" .  Called 
yX,  by  semantic-checks  if  there  are  no  errors  to  determine  uuich  export-obj 

y,y,  sill  serve  as  the  source  of  the  data  to  be  requested  by  each  import-obj . 

yXt  If  no  source  currently  exists,  go  figure  out  shich  one  to  use 
Xy,  (via  get-source);  else,  present  the  currently  specified  to  the  user 
yX>  who  may  sant  to  (and  can)  ch^mge  it. 
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n 

function  determine-import-sources  (subsystem  :  subsystem-obj)  = 

enumerate  import  over  import-area(subsystem)  do 

if  empty(source(import))  then  '/•  no  source  currently  specified 
get-source( import } 

else 


(if  size(source(import))  =  1  then 

*U  a  particular  source  mas  selected  previously 
let  (source-info  :  source-obj  =  arb(source(import))) 


format (t, 

format (t, 

format (t, 

format (t, 
format (t , 
format (t, 


"■%*!4There  is  already  a  source  specified  for  *s 
import-name ( import) ) ; 

"  which  is  used  by  object  *s 

consumer ( import ) ) ; 

”  in  subsystem  "s 

name (parent-ezpr (import) ) ) ; 

"  The  source  is:  's'X'*,  source-name(source-info)) ; 

"  produced  by  object  "s")!",  sourco-object(source-info)) ; 

"  in  subsystem  's'*/.",  source-subsystem(source-info)) 


else 


); 


format (t,  "*'/.An  arbitrary  source  is  to  be  used  for  's'*/.", 
import-name ( import ) ) ; 

format(t,  "  which  is  used  by  object  's"’/,", 

consumer ( import ) ) ; 

format(t,  "  in  subsystem  "s*'/,", 

name (parent-ezpr ( import ) ) ) 


%■ 


if  (lisp: :y-or-n-p("Do  you  want  to  select  a  different  source?"))  then 
get-source ( import ) 


jr - 

% - 

y.y.  PREPR0CESSII6  UTILITIES 

54 - 

54 - 


54 - 

%%  Get-Source  —  Used  by  Determine- Import-Sources .  First,  sets  the  import’s 
%%  source  to  the  null  set  (either  it  is  null  to  steort  or  the  user  wants  to 

%%  wipe  out  what  is  already  there.  Then  find  all  export -objs  within  the 

%%  same  application  definition  (spec-obj)  which  can  provide  the  kind  of 

V!l%  data  needed  by  import.  If  only  one  ezport-obj  can  be  the  source,  use  it. 
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X%  otherwise ,  present  the  possible  choices  to  the  user  who  must  specify 
%%  which  one  he  wants  to  use. 

function  get-source (import  :  import-obj)  = 

set-attrs( import,  'source,  {});  X  wipe  out  whatever  was  there 

let  (export-seq  ;  seq(export-obj)  = 

[source-export  I  ( source-export :oxport-obj) 
export-obj (source-export)  ft 

oxport-category(so\xrco-oxport)  =  import-category(import)  ft 
up-to-root(source-oxport)  =  up-to-root( import)  ft 
subsystem-obj (parent-expr((sourco-export)))] ) 
y.  added  this  last  one  so  it  won't  find 
X  the  import/export-objs  which  are  in  the  variables 
X  (e.g.  THIIG-OBJ-IIPOT) 
if  size(export-seq)  <  1  then 

XX  Error  -  should  not  occur  at  this  time; 

XX  Supposed  to  catch  this  error  during  semantic  checks; 

XX  this  is  called  only  if  there  are  no  errors . . . 
format(t,  "Error:  Ho  subsystem  provides  "s  type  of  data'X", 
symbol-to-str ing( import-category ( import ) ) ) ; 

undefined 

elseif  aize(export-seq)  1  then 
format (debug-on , 

"There  is  only  one  possible  source  for  this  info;  use  it'X"); 
set-import-source ( import ,  {export-seq( 1 ) } ) 


else 

XX  More  than  one  subsystem  provides  this  data-item. 

XX  Prompt  the  user  to  select  the  one  to  be  used. . . 

XX  and  store  its  name  for  future  reference 

XX  OR  if  user  doesn't  care  where  data  comes  from,  store 

XX  all  possible  choices . . . 

let  (user-choice  :  integer  =  prompt-for-source( import,  export-seq)) 

(if  user-choice  <=  size(export-seq)  then 

XX  User  has  selected  a  particular  source  for  this  data; 

XX  set  source  (import)  to  this  selected  source  only... 
set-import-source(import,  {export-seq(usor-choice)}) 
else 

XX  User  has  indicated  he  doesn't  care  where  import  data 
XX  comes  from;  set  source (import)  to  all  the  possible  sources 
8et-import-Bource( import,  seq-to-set (export-seq)) 


% - 

XX  Set-Import-Source  —  loops  through  all  export-objs  in  set-to-set. 
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XX  creating  a  nev  source-obj  lor  each  element  of  set-to-set  and  setting 
XX  its  attributes  (source-subsystem  and  source-object),  based  on 
XX  info  in  and  about  each  element  of  set-to-set.  Called  by  Get-Source 

function  set-import-source (import  :  import-obj, 

set-to-set  :  set(export-obj))  = 

enumerate  x  over  set-to-set  do 

let  (s  :  source-obj  =  make-object (’source-obj)) 
source-subsystem(s)  <-  name(parent-expr(x)) ; 

source-object (a)  <-  producer(x); 

source-name(s)  <-  export-name(x) ; 

source (import)  <-  source (import)  with  s 

% - 

% - 

XX  Prompt-for-Source  —  given  a  sequence  of  export-objs  to  choose  from, 

XX  display  each  possible  choice  and  prompt  the  user  to  choose  one. 

XX  The  last  choice  is  always  "don’t  care",  i.e.,  qse  arbitrary  source. 

XX  Returns  number  chosen  by  the  user. 

function  prompt-for-source  (import  :  import-obj , 

seq-to-choose-from  :  seq(export-obj))  :  integer  = 

fonaat(t,  "'XNore  than  one  export  can  provide  the  data  for  's'X", 

import-name(import)) ; 

format(t,  "  which  is  used  by  object  's'X", 

consumer  (import)) ; 

format(t,  "  in  subsystem  's'X", 

name (parent-expr( import) ) ) ; 

format(t,  "Choose  the  export  item  (subsystem  and  component) *X") ; 
format(t,  "  that  you  wish  to  be  the  source  of  this  data:'X"); 

(enumerate  index  from  1  to  size(seq-to-choose-from)  do 
format(t,  "  'd>  subsystem  's  component  's  name  's'X", 

index, 

symbol-to-string(name(parent-expr(seq-to-choose-from(index) ) ) ) , 
symbol-to-8tring(producer(seq-to-choose-from( index))) , 
symbol-to-string(export-name(seq-to-cboose-from(index) ) ) ) 

): 

format (t,  "  'd>  Specific  source  not  required;  use  arbitrary  one'X", 

size(seq-to-choo8e-from)+l) ; 

format(t,  "Enter  the  number  corresponding  to  the  source  you  want  to  use'X"); 
read-input() 

X - 

XX  The  following  functions  are  used  when  handling  identifiers  in  "if"  and 
XX  "while"  conditions.  As  they  deal  with  import  and/or  export  areas,  these 
XX  functions  have  been  placed  in  vhis  file  to  localize  any  import/export 
XX  changes  (and  there  have  been  a  lot  of  them!). 
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XX  Eztract-and-Set-Id-Source  —  Separates  the  consiuner/producer  from  the 
XX  id  name  and  uses  this  info  to  find  the  appropriate  import  or  export 
XX  object  for  the  id’s  source.  The  separator  is  a  constant  which  is  set 
XX  in  globals . re 

function  extract-and-set-id-source  (  id  :  identifier  )  = 

let  (id-name-string  :  string  =  symbol-to-8tring(id-name(id))) 

let  (source-object -name  :  string  =  X  consumer/producer  name 

source-name  ;  string  =  X  id  name 

position-of-separator  :  integer  =  size(id-name-string)+l) 

X  Extract  the  consnmer/producer  name  and  id  name 

(enumerate  index  from  1  to  size (id-name-string)  by  1  do 
if  id-name-string(index)  =  separator  than 
position-of-separator  <-  index 
elseif  position-of-separator  >  size(id-name-string)  then 
source-object -name  <- 

append(sonrce-object-name ,  id-name-string(indez) ) 

else 

source-name  <-  append(source-name,  id-name-string (index)) 

); 


set-attrs(id,  'id-source,  undefined);  %  wipe  out  what  was  there 

let  (subsystem  :  subsystem-obj  = 

least-ancestor-of-class ( id ,  ’ subsystem-obj ) ) 

let  (intport-set  :  set(object)  = 

{import  I  ( import :import-obj)  import-obj( import)  t 
import  in  import -area( subsystem)  t 

import -name (import)  =  string-to-symbol( source-name,  "RU")  t 
consumer  (import)  =  string-to-s3ni>bol(source-object-name,  "RU")>, 

export-set  :  set (object)  = 

{export  I  (export :export-obj)  export-obj (export)  * 
export  in  export-area(subsystem)  R 

export-name (export)  =  string-to-symbol (source-name,  "RU")  t 
producer(export)  =  string-to-symbol(source-object-name,  "R0")» 

let  (possible-choices  :  seq(object)  = 

8et-to-seq(import-set  union  export-set)) 

if  ampty(possible-choices)  then 
format(t, 

"There  is  no  possible  data  in  subsystem  for  conditional  identifier  *s  *X", 
id-name (id)) 

elseif 
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8ize(po8sible-choices)  =  1  than  %  there  ia  only  1  place  to  get  this  info 
set-attrsCid,  'id-sonrce,  possible-choicesCl)); 

8et-attrs(id,  'id-naae,  string-to-symboKsonrce-name,  "RU")) 
else  %  The  qualification  was  not  precise  enough 
format(t,  "More  than  one  import/ezport  item  meets  the  qualification. *%"} ; 
format  (t,  "  Please  contact  the  softvare  engineer /domain  engineer.  *'/.") 


X - 

6et-Id-Source-for-Conditional  —  First,  sets  the  identifier’s 
%%  source  to  undefined  (either  it  is  null  to  start  or  the  user  sants  to 

y,y,  wipe  out  what  is  already  there).  Then  find  all  import/ezport-objs  vithin 

XX  the  subsystem  which  could  be  the  source  of  data  for  this  id  (i.e.,  that 

XX  have  the  same  name.  If  only  one  can  be  the  source,  use  it.  Otherwise, 

XX  present  the  possible  choices  to  the  user  who  must  specify  which  one  he 
XX  wants  to  use. 

function  get-id-source-for-conditional  (  id  :  identifier  )  = 

set-attrsCid,  ’id-source,  undefined);  X  wipe  out  what  was  there 

let  (subsystem  :  subsystem-obj  = 

least-ance8tor-of-cla8s(id,  ’subsystem-obj)) 

let  (import-set  :  8et(object)  = 

{import  I  ( import :import-obj)  import-obj (import)  k 
import  in  import-area(sub8ystem)  k 
import-name(import)  -  id-naffle(id)}, 

export-set  :  set (object)  = 

{export  I  ( export :export-obj)  export-obj (export)  k 
export  in  export-area(sub8ystem)  k 
export-name (export)  =  id-name (id)}) 

let  (possible-choices  :  8eq(object)  = 

8et-to-seq(import-set  union  export-set)) 

if  empty(po88ible-choices)  then 
format(t, 

"There  is  no  possible  data  in  subsystem  for  conditioneil  identifier  *s  *X", 
id-name (id)) 

else 

if  size  (possible-choices)  =  1  then  X  there  is  only  1  place  to  get  this  info 
format (t,  "There  is  only  one  possible  choice  for  's,  so  select  it'X", 
id-name(id)) ; 

set-attrs(id,  ’id-source,  possible-choices(l)) 
else  X  ask  the  user  which  import/export  obj  to  use  for  source 
let  (choice  :  integer  = 

prompt-for-conditional-source(id-name(id) ,  possible-choices)) 
8et-attrs(id,  ’id-source,  possible-choices (choice)) 


X 
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% - 

Prompt-! or-Conditional-Source  —  very  similar  to  Prompt-lor-Source 
%%  but  the  printing  format  and  messages  are  a  little  different. 

Given  a  sequence  of  ezport-objs  to  choose  from,  display  each  possible 
XX  choice  and  prompt  the  user  to  choose  one. 

XX  C2Qled  by  get-id-source-for-conditional. 


f unct ion  prompt -f or-condit ional-source 

(looking-for  :  symbol, 

seq-to-choose-from  :  seq(object))  :  integer  = 

format(t,  "There  is  more  than  one  possibility  for  data  with  name  *s~X",  looking-for); 

formatCt,  "  Choose  the  data  you  would  like  to  use  for  evaluating  the  conditional'X") ; 

(enumerate  index  from  1  to  size(seq-to-choose-from)  do 
if  import-obj(aeq-to-choose-from(indox))  then 

format (t,  "  ''d>  In  import  area  of  subsystem  ~s:  consumer  =  *s:  name  =  's'X", 

index,  name(parent-expr(seq-to-choose-from(index))) , 
consumer(seq-to-choose-f rom(index) ) , 
import -name (seq-to-choose-from( index) ) ) 

else 

format(t,  "  *d>  In  export  area  of  subsystem  *s:  producer  =  's:  name  =  's’X", 

index,  name(parent-expr(seq-to-choose-from(index))) , 
producer (seq-to-choose-from(index) ) , 
export-name(8eq-to-choose-f rom(index) ) ) 

): 

read-input () 


X - 

X - 

XX  ACCESSIIG  INPORT/EXPORT  AREAS  —  Used  during  behavior  simulation  (execution) 

X - 

X - 

XX  Get-Import  —  returns  the  value  of  an  external  data  item. 

XX  Given  an  id-name  and  consumer,  function  finds  the  import-obj  associated 
XX  with  that  id.  If  the  source  attribute  is  defined  (we  have  already 

XX  used  this  id  before  and  know  where  to  get  the  data) ,  can  go  directly 

XX  to  right  subsystem's  export-area  and  return  the  value.  If  not, 

XX  (we  haven't  used  this  id  yet),  must  try  to  find  an  export-obj  with 

XX  the  same  id  in  another  subsystem.  If  there's  only  one  subsystem 

XX  with  that  id  in  its  export-area,  that’s  the  one  to  use:  return  its 

XX  value  and  set  the  import-obj  source  to  that  subsystem  name.  If  there 

XX  are  more  than  one,  prompt  the  user  to  specify  which  subsystem  to  use  as 
XX  the  source.  Set  the  source  to  that  subsystem/object  (so  user  doesn't  have 
XX  to  be  prompted  again)  and  return  the  appropriate  value. 

XX  lOTE:  changes  when  source  was  made  a  set:  if  the  set  is  empty  (have  not 
XX  yet  tried  to  access  this  data),  find  all  possible  sources.  Prompt  the 
XX  user  to  select  one  of  the  possible  sources  or  "arbitrary  source" .  If 
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a  particular  source  was  selected,  source  has  only  that  entry.  If 
"arbitrary"  uas  chosen,  source  contains  all  the  possible  choices.  In 
XX  either  case,  select  an  arbitrary  member  of  the  source  set. 

function  get-import  (id-name  :  symbol, 

subsystem  :  subsystem-obj , 

consumer-obj  :  primitive-obj)  :  any-type  = 

let  (import  :  import-obj  = 

arb(-Cimport  I  (import: import-obj)  import-obj (import)  ft 
import  in  import-area(subsystem)  ft 
import-name (import)  =  id-name 
ft  consumer (import)  =  name(consumer-obj)})) 

if  undefined? (import)  then 

XX  Oops!  This  shouldn’t  happen.  If  it  doss,  dm  and  code  for  primitive 
XX  object  must  be  checked  to  ensure  compatibility  WRT  input-data. . . 
format (t,  "1  run-time  error  has  occurred.  There  is  no  import-obj  for  *s"X", 
id-name) ; 

format(t.  "  uhich  is  used  by  *s  in  subsystem  *s*X",  name( consumer-obj) , 
name (subsystem)) ; 

format(t,  "Please  contact  the  software  engineer'X") ; 
undefined 
else 

if  'empty(source(import))  then 

XX  Ve  know  which  subsystem  has  this  info; 

XX  go  directly  to  the  right  one 

let  (s  :  source-obj  - 

arb(source(import)))  X  if  there  is  only  one  source  specified, 

X  automatically  gets  the  correct  one 
let  (source-sub  :  subsystem-obj  = 

f ind-object( ’ subsystem-obj ,  source-subsystem(s) ) ) 
let  (source-export  :  export-obj  = 

arb(-Csource-export  I  (source-export: export-obj) 
export-obj (source-export)  ft 
source-export  in  export-area(source-sub)  ft 
export-name (source-export)  =  source-name (s)  ft 
producer(source-export)  =  source-object(s)})) 

(if  undef ined?(value(source-export))  then 

format(t,  "The  export  item  corresponding  to  "s  which  is  used  by'X", 
id-name) ; 

format (t,  "  *s  in  subsystem  *s  has  not  yet  been  set.'X", 
name (consumer-obj) ,  name(subsystem)) 

); 

value ( source-export ) 
else 

XX  We  don’t  yet  know  which  subsystem  will  provide  this  info. 

XX  So,  there  must  have  been  some  error  in  our  preprocessing. . . 
format(t,  "A  run-time  error  has  occurred.  There  is  no  source  for  "s*X", 
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id-name) ; 

lormat(t,  "  shich  is  used  by  *s  in  subsystem  's'%",  name(consumer-obj) , 
name (subsystem) ) ; 

format (t,  "Please  contact  the  software  engineer .'%") ; 
undefined 

% - 


% - 

Set-Export  —  set  the  value  attribute  of  the  export-obj 
%%  whose  export-name  attribute  =  id-name  to  V2Q..  This  makes  val 
XX  available  to  external  subsystems. 


function  set-export  (subsystem 

source-obj 

id-name 

ved 


:  subsystem-obj . 
:  primitive-obj , 
:  symbol . 

:  emy-type)  = 


lot  (export  :  export-obj  = 

arb({export  |  (export; export-obj)  export-obj (export)  k 
export  in  export -area( subsystem)  k 
export -name (export)  =  id-name  k 
producer (export)  =  name (source-obj)})) 


if  undefined? (export)  then 

XX  Oops!  This  shouldn’t  happen.  If  it  does,  dm  and  code  for  primitive 
XX  object  must  be  checked  to  ensure  compatibility  VRT  output-data... 
format (t, 

"You  have  tried  to  export  a  value  which  is  not  in  object's  output-data'X") 

else 

set-attrs( export,  'value,  val) 


% - 

XX  Get-Id-Type-For-Conditional  —  If  id-source  for  id  has  not  boon  specified, 

XX  rettim  ERROR  to  caller  (to  avoid  unusual  run-time  error;  should  always 

XX  have  a  source  by  this  time);  otherwise,  return  the  data  type  of  the  data  to 

XX  be  used  as  source  of  id.  Called  by  eval-expr  during  semantic  checking 
XX  of  boolean  expressions. 

function  get-id-type-for-conditional  (  id  :  identifier  )  :  symbol  = 
if  undefined?(id-source(id))  then 

format(t,  "Id  's  has  not  been  associated  with  an  import/export-obj ~X" , 
id-name(id)) ; 

'ERROR 

elseif  import-obj( id-source (id))  then 
import-type-data(id-source(id) ) 
else 

export-type-data(id-oource(id) ) 
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X - 

y,%  Get-Id-Valua-lor-Conditional  —  Retrieves  the  current  value  oi  id. 

%%  It  id-source  is  an  import-obj,  must  used  get-import  to  obtain  the  value 

yjf,  (since  the  V2^.ue  isn’t  stored  in  an  import-obj).  If  id-source  is  an 

%%  export-obj,  get  the  value  directly  for  it.  Id-source  should  2Qready 
Xy.  be  defined. . . 

function  get-id-veG.ue-for-conditional  (  id  :  identifier  )  :  any-type  = 

if  undefined? (id-source (id))  then  %  something  strange  is  going  on 
'ERROR 

elseif  import-obj (id-source (id))  then 

get-import(id-name(id) ,  parent-expr(id-source(id)) , 

f ind-ob j  ect ( ’ pr imit ive-ob j ,  consumer ( id-source ( id) ) ) ) 

else 

value ( id-source ( id) ) 

X - 

X - 

51 - 

%%  GEIERAL  UTILITIES 

5i - 

5i - 

%y,  get-input-output-variable  —  returns  the  set  of  input-data  or  output-data 
y,X  associated  sith  that  object  tjrpe.  Each  domain  object  class  has  two 
X%  variables:  objectclass-IIPUT-OATA  and  objectclass-OUTPUT-DATA  uhich 
XX  define  the  input-data  and  output-data  associated  «ith  domain  objects 
XX  of  that  type.  This  function  constructs  the  correct  variable  name 
XX  (by  concatenating  object  class  (of  input  parameter,  obj),  -,  and 
XX  IIPUT-DATA  or  OUTPUT-DATA  (from  input  parameter,  in-or-out)). 

XX  It  then  calls  the  lisp  function,  symbol-value,  using  the  constructed 
XX  variable  name,  and  returns  that  value. 

XX  lOTE:  Input-data  and  output-data  for  each  object  class  MUST  follow  this 

XX  naming  convention. 

function  get-input-output -variable (obj  :  primitive-obj , 

in-or-out  :  string)  :  set (any-type)  = 

let(  oc  :  re:: binding  =  instance-of (obj)) 
let(var-name  :  symbol  = 

string-to-symbol(concat(symbol-to-string(namo(oc)) ,  in-or-out),  "ru")) 

symbol-value ( var-neuae ) 


5j - 

XX  Get-Source  —  Used  by  Determine-Import-Sources.  First,  sets  the  import’s 
XX  source  to  the  null  set  (either  it  is  null  to  start  or  the  user  wants  to 
XX  wipe  out  what  is  already  there.  Then  find  all  export-obj s  within  the 


X%  same  application  delinition  (spec-obj)  shich  can  provide  the  kind  of 

%%  data  needed  by  import.  If  only  one  export-obj  can  be  the  source,  use  it. 

Otherwise,  present  the  possible  choices  to  the  user  who  must  specify 
%%  which  one  he  wants  to  use.  Called  by  Determine- Input-Sources. 

function  get-source (import  :  import-obj)  = 

set-attrs( import,  'source,  {});  %  wipe  out  whatever  was  there 

let  (export-seq  :  seq( export-obj)  = 

[source-export  I  (source-export: export-obj) 
export-obj (source-export)  t 

oxport-category(source-export)  =  import-category(import)  k 
up-to-root(source-oxport)  =  up-to-root( import)  k 
subsystem-obj (parent-oxpr( (source-export) ) )] ) 

%  added  this  last  one  so  it  won’t  find 
V.  the  import/export-objs  which  are  in  the  variables 
•/.  (e.g.  THIHG-OBJ-IIPUT) 
if  size(export-seq)  <  1  then 

%%  Error  -  should  not  occur  at  this  time; 
y,y.  Supposed  to  catch  this  error  during  semantic  checks; 
this  is  called  only  if  there  are  no  errors . . . 
format(t,  "Error:  lo  subsystem  provides  "s  type  of  data*y,", 
symbol-to-string(impozi;-category (import) ) ) ; 

undefined 

elseif  size(export-seq)  =  1  then 
format (debug-on, 

"There  is  only  one  possible  source  for  this  info;  use  if'/,"); 
set-import-source (inq)ort,  {export-seqd)}) 


else 

'l%l%  More  than  one  subsystem  provides  this  data-item. 

%%  Prompt  the  user  to  select  the  one  to  be  used. . . 

'/.y,  and  store  its  name  for  future  reference 

OR  if  user  doesn't  care  where  data  comes  from,  store 
all  possible  choices . . . 

let  (user-choice  :  integer  =  prompt-for-80urce( import,  export-seq)) 

(if  user-choice  <=  size(export-seq)  then 

'!!/,  User  has  selected  a  particular  source  for  this  data; 

%!(  set  source  (import)  to  this  selected  source  only... 
set-import-source (import,  •(export-seq(user-choice)}) 
else 

VHt  User  has  indicated  he  doesn’t  care  where  import  data 
*/,y.  comes  from;  set  source  (import)  to  all  the  possible  sources 
set-import-source(import,  seq-to-set (export-seq)) 

) 

jj - 
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D.5  Semantic-Checks 


! !  in-package ("RU") 

!!  in-granmarC’user) 

%Y,  File  name:  semantic-checks. re 


Y'/»  The  rules  that  invoke  the  individual  tests  on  the  subsystem  assume  that  the 
%%  subsystem  is  the  current  object  (not  the  spec  object).  The  main  rules 
y.%  (Check-belore-executing  and  reset-fatal-error)  can  be  executed  from  the 
spec-obj 


jj - 

%%  Check-Semantics  —  applied  on  the  current  node,  a  spec-obj 

rule  Check-Semantics  (x  ;  object) 
true  — > 

Perf orm-Semantic-Checks (X) 

% - 


% - 

y,y,  Perform-Semantic-Checks  —  enumerates  over  all  the  kids  of  the  spec-obj,  x, 
%y.  calling  the  appropriate  check  function  for  the  kind  of  object  encountered 
y.y.  (application  or  subsystem)  . 

%%  There  are  currently  no  semantic  checks  for  primitive  objects. 


function  Perform-Semantic-Checks  (X  :  object)  = 

%%  X  is  root  of  abstract  syntax  tree,  spec-obj 

FATAL-ERROR  <-  false;  %  Reset  it  so  only  nes  errors  will  be  flagged 

Semantic-Checks-Performed  <-  true,  %  So  se  know  these  checks  actually  sere  done 

let  (components  :  seq(symbol)  =  [] ,  Y,  used  for  checking  unused  components 

application-objs  :  seq(application-obj)  =  [])  %  used  for  checking  too  many/too  fen 

Y,  applications 

(enumerate  obj  over  kids(x)  do 

if  application-obj (obj)  then 

application-objs  <-  append(application-objs,  obj); 
components  <-  concat (components,  Cname(obj)], 

set-to-seq(seq-to-set (application-components (obj ) ) ) ) ; 

check-application(obj) 
elseif  subsystem-obj (obj)  then 
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components  <-  concat ( components , 

set-to-seq(seq-to-set (controllees (ob j ) ) ) ) ; 

%  VOTE:  set-to-seq(seq-to-set)  is  necessary  to  ensure  there  is  only  1 
y.  occurrence  oi  each  controllee.  Making  controllees  a  set  to  start  with 

%  did  not  assure  only  unique  controllee  names 

build-import-export-area(obj) ;  build  framework  for  im/ex  area  -  "preprocessing" 
determine-sources-for-conditionals(obj) ;  %  more  "preprocessing" 

check-subsystem(obj ) 


%%  low,  all  import/export  areas  in  the  entire  application  have  been  built. 
%%  Can  check  that  eill  imports  have  a  corresponding  export 
(enumerate  obj  over  kids(x)  do 
if  subsystem-obj(obj)  then 

Check-for-Export3-Corresponding-to-Imports(obj) 

); 


%y.  Do  we  have  one  and  only  one  application-obj? 

(if  size(application-objs)  =  0  then 

Report-Error ("There  is  no  application  executive  in  your  specification",  X) 
else 

if  size(application-objs)  >  1  then 

Report-Error ("There  are  too  many  application  executives  in  your  specification",  X) 

); 


y.y«  Zs  a  specific  primitive  object  instance  used  in  more  than  one  subsystem? 
(let  (dup-seq  :  seq(symbol)  =  f ind-all-dups  (components)) 
enumerate  y  over  dup-seq  do 

if  primitive-obj(find-object(’component-obj,  y))  th?a 
Report-Error (concat( "Object  ",  symbol-to-string(y) , 

"  appears  in  more  than  one  subsystem") ,  X) 

); 


V/,  Are  there  any  unused  components  in  the  spec-obj? 

(let  (xinused-components  ;  set(component-obj)  = 

{z  i  (z : component-ob j )  component-obj (z)  A  name(z)  'in  components  A 
up-to-root(z)  =  X}) 
enumerate  y  over  unused- components  do 

Report-Waming(concat("Objoct  ",  symbol-to-string(name(y)) , 

"  is  not  used  in  the  proposed  application"),  X) 

): 


V/,  If  no  errors  so  far,  determine  sources  for  all  imports  (part  of  "preprocessing") 
if  'FATAL-ERROR  then 

enumerate  component  over  kids(x)  do 
if  subsystem-obj (component)  then 

determine- import- sources ( component ) 

- 

% - 

’/,%  Check-Application  —  ensures  application  constraints  are  met,  including: 
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%%  Check-If-Application-Components-Exist:  (ERROR) 

y,y.  Self-explanatory. 

%%  Check-f or-Direct-Use-of-Primitives :  (ERROR) 

%%  Ensures  no  primitive  objects  are  included  in  the  application  directly 

VU  (i.e.,  without  an  intervening  subsystem) 

Xy,  Check-Application-Update-Proced\ire  —  Ensures  that  operands  are  part  of  the 

Xy  application  (i.e.,  included  in  application-components)  and  also  includes 

%%  the  following  check: 

%%  Check-For-Legal-Call-Statement;  (ERROR) 

Ensures  that  only  call  statements  are  included  in  application-update 
%%  (no  If  or  While)  and  that  only  implemented  subsystem  interfaces  are 

y,%  used  (now,  that’s  only  update!). 

y,y,  Check-For-Dupes-in- Application-Components:  (WARIIHG) 

*lil.  Checks  that  each  component  appears  only  once.  If  not,  this  may 

%%  indicate  a  specification  error  (especially  a  typo) ,  although  the 

%%  application  can  be  executed. 

'1*1%  Check-For-Unused-Components-in-Update:  (WARHIIG) 

y,X  Checks  for  unused  components  in  the  update  procedure  (i.e.  components 

'lil,  listed  in  application-components  but  not  used  as  operands  in  the  update 

%%  procedure).  Again,  this  could  indicate  a  specification  error... 

function  check-application  (application  :  application-obj)  = 

Check-If-Application-Components-Exist  (application) ; 
Check-for-Direct-Use-of-Primitives  (application) ; 

Check-Application-Update-Procedure  (application) ; 
Check-For-Dupes-in-Application-Components  (application) ; 
Check-For-Unused-Subsystems-in-Update  (application) 

% - 

% - 

XX  Check-If-Application-Components-Exist  —  Ensures  all  application-components 
XX  exist  that  should  exist.  If  some  do  not  exist,  are  they  to  be  initialized 
XX  by  the  application  update  procedure?  If  so,  that’s  OK. 

XX  Generates  an  ERROR. . . 

function  check-if-application-components-exist  (application  ;  application-obj)  = 

enumerate  component  over  application-components (application)  do 

if  'object-exists( component)  then  X  no  such  subsystem  with  that  name 
Report-Error 

(concatC Object  ",  symbol-to-string ( component ) ,  "  does  not  exist"), 
application) 

jr - 

- 

XX  Check-f or-Direct-Use-of-Primitives  —  Ensures  that  no  primitive  objects  are 
XX  used  directly  by  the  application  (application  should  deal  only  with  subsystems) . 

function  Check-f or-Direct-Use-of-Primitives  (application  :  application-obj)  = 

enumerate  x  over  application-components(application)  do 
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if  primitive-obj (lind-object(’component-obj ,  x))  then 
Report -Error ( concat ( syinbol-to-string(x) , 

"  is  a  primitive;  only  subsystems  can  be  used  in  application"), 
application) 

% - 

- 

y,*/,  Check-Application-Update-Procedure  —  Ensures  that  all  statements  in 
Xy  application  update  procedure  are  legal.  Includes: 

function  check-application-update-procedure  (application  :  application-obj)  = 

if  size  (application-update  (application))  =  0  then 

Report-ErrorC'Io  statements  in  application  update  procedure",  application) 
else 

enumerate  stmt  over  application-update(application)  do 
if  if-stmt-obj(stmt)  then 

Report-Error ("If  statements  are  not  allowed  in  application  update  procedure", 
application) 

elseif  vhile-stmt-obj(stmt)  then 

Report-ErrorC'While  statements  are  not  alloved  in  application  update  procedure", 
application) 

else  y.  have  a  call  statement 

check-if-operand-in-application  (application,  stmt) ; 
check-for-legal-call-stmt  (stmt) 


% - 

XX  Check-If-Operand-in-Application  —  Operand  of  call  statement  must  be  included 
XX  in  application’s  application-components. 

function  check-if-operand-in-application  (application  :  application-obj , 

stmt  ;  statement-ob j )  = 

if  operand(stmt)  *in  application-components(application)  then 
Report-Error  (concat  ("Object  ",  symbol-to-string(operand(stmt)) , 

"  is  not  part  of  the  application"),  application) 

5i - 

XX  Check-For-Legal-Call-Stmt  — 

XX  Ensures  that  only  subsystem  procedural  interfaces  (update,  destroy, 

XX  initialize,  configure  and  stabilize  (the  last  four  are  not  yet  implemented, 

XX  though))  are  used  in  application  update  procedure. 

XX  Generates  an  ERROR. . . 

function  check-for-legal-call-stmt  (stmt  :  statement-obj)  = 
if  configure-czJ.l-obj (stmt)  then 

Report-Error  ("Configure  not  yet  implemented  ",  stmt) 
elseif  8tabilize-ceJ.l-obj(stmt)  then 

Report-Error  ("Stabilize  not  yet  implemented  ",  stmt) 
elseif  initialize-cadl-obj (stmt)  then 

Report-Error  ("Initialize  not  yet  implemented  " ,  stmt) 
elseif  destroy-call-obj (stmt)  then 

Report -Error  ("Destroy  not  yet  implemented  ",  stmt) 
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elseil  'update-call-obj(stmt)  than 

Report-Error  ("Illegal  operation  in  an  application  update  procedure",  stmt) 

% - 

% - 

VX  Check-lor-Dupes-in-Application-Components  —  Are  any  subsystems  listed  more 
fX,  than  once  in  application-components?  If  so,  user  may  have  made  an  error 
VL  (most  likely  a  typo).  Generates  a  Warning... 

function  check-for-dupes-in-application-components  (application  :  application-obj)  = 

let  (dup-subsystems  :  seq(symbol)  =  find-ed.l-dups  (application-components(application))) 

if  size(dup-subsystems)  '=  0  then  %  Have  dupes  within  components  of  single  application 
enumerate  dupe  over  dup-subsystems  do 

Report-Haming(concat("Subsystem  ",  symbol-to-string(dupe) , 

"  appears  more  than  once  in  the  application”) ,  application) 


- 

% - 

Check-For-Unused-Subsystems-in-U^ate  —  Are  any  subsystem  not  used  in  the 
XX  application  update  procedure?  If  any  are  unused,  it  could  indicate  an  error 

XX  by  the  user  (either  a  typo  or  perhaps  he  forgot  to  include  an  update 

XX  statement).  Generates  a  Warning. . . 

function  Check-For-Unused-Subsystems-in-tlpdate  (application  :  application-obj)  = 

let  (subsystems-unused  :  set(symbol)  =  seq-to-set (application-components (application))) 

(enumerate  stmt  over  application-update(application)  do 

subsystems-unused  <-  f ind-unused-components(subsystems-unused,  application,  stmt) 

); 

if  'empty (subsystems-unused)  then 

enumerate  unused  over  subsystems-unused  do 

Report-Warning  (concat  ("Subsystem  ",  symbol-to-string(unused) , 

"  not  used  in  application  update"),  application) 

% - 


X - 

XX  Check-Subsystem  —  ensures  subsystem  OCO  constraints  are  met. 

XX  Check-If-Controllees-Exist :  (ERROR) 

XX  Ensures  all  controllees  exist. 

XX  Check-Subsystem-Update-Procedure  —  includes  the  following  checks 
XX  Check-If-Statement ;  (ERROR) 

XX  Ensures  that  if-cond  is  valid.  Then  checks  that  all  statements 

XX  in  then  and  else  clauses  are  OK 

XX  Check-While-Statement :  (ERROR) 

XX  Ensures  that  if-cond  is  valid.  Then  checks  that  all  statements 

XX  in  then  and  else  clauses  are  OK 

XX  Check-If-Operand-in-Subsystem:  (ERROR) 

XX  Ensures  the  operand  of  call  statement  is  part  of  the 

XX  current  subsystem  (i.e.,  it  appears  in  "controllees") 
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7,%  Check-SetFuact  ion-stmt:  (ERROR) 

XX  Ensures  function-name  is  valid  lor  operand;  ensures  stmt 

XX  coefficients  are  valid  for  operand. 

XX  Check-SetState-Stmt :  (ERROR) 

XX  Ensures  state  names  are  valid  for  operand  and  the  neu  value 

XX  provided  for  them  is  of  the  appropriate  type. 

XX  Check-For-Dupes-in-Subsystem:  (UARIIIG) 

XX  Checks  that  each  controllee  name  appears  only  once.  If  not,  this  may 

XX  indicate  a  specification  error  (especially  a  typo),  although  the  application 

XX  can  be  executed. 

XX  Check-For-Unused-Components-in-Update:  (WARIIIG) 

XX  Checks  for  unused  components  in  the  update  procedure  (i.e.  components  listed 

XX  as  controllees  but  not  used  as  operands  in  the  update  procedure).  Again, 

XX  this  could  indicate  a  specification  error... 

function  check-subsystem( subsystem  :  subsystem-ob j )  = 

Check-ll-Controllees-Exist (subsystem) ; 

Check-Subsystem-Update-Procedure(subsy8tem); 

Check-For-Dupes-in-Subsy8tem(subsystem); 

Check-For-Unused-Components-in-Update(sub8y8tem) 

X - 

X - ^ - 

XX  Check-If-Controllees-Exist  — 

XX  Ensures  all  controllees  exist  that  should  exist.  If  some  do  not  exist, 

XX  are  they  to  be  created  by  the  subsystem?  If  so,  that's  OK. 

XX  Generates  an  ERROR. . . 

function  Check-If-Controllees-Exist  (subsystem:  subsystem-obj)  = 

enumerate  ctrlee  over  Controllees (subsystem)  do 

if  'object-exists (ctrlee)  then  X  no  such  object  with  the  given  name 
Report-Error(concat( "Object  ",  8ymbol-to-string(ctrlee) , 

"  does  not  exist"),  subsystem) 

% - 

54 - 

XX  Check-Subsystem-Update-Procedure  —  Ensures  that  edl  statements  in 
XX  subsystem  update  procedure  are  legal.  Includes: 

function  check-subsystem-update-procedure  (subsystem  :  subsystem-obj)  = 

if  size(update(subsystem))  =  0  then 

Report-Error ("lo  statements  in  subsystem  update  procedure",  subsystem) 
else 

enumerate  stmt  over  update (subsystem)  do 
check-stat  ement ( stmt ) 


54 - 

XX  Check-Statement  —  checks  a  particular  statement.  It’s  a  separate  function 
XX  so  it  can  be  called  within  if  2uid  while  statements. 
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function  check-statement  (stmt  :  statement-obj)  = 


if  if-stmt-obj (stmt)  then 
check-if-statement (stmt) 
elseif  while-stmt-obj(stmt)  then 
check-9hile-statement(stmt) 
else  %  have  a  call  statement 

check-if-operand-in-subsystem(stmt) ; 
if  setfunction-call-obj (stmt)  then 
check-setf unction-stmt (stmt) 
elseif  setstate-call-obj (stmt)  then 
check-setstate-stmt(stmt) 
elseif  ~update-call-obj(stmt)  then 

Report-ErrorC'Qperation  is  not  yet  implemented”,  stmt) 

% - 

VL  Check-lf-Operand-in-Subsystem  —  Operand  of  csdl  statement  must  be  included 
%%  in  subsystem's  controllees. 

function  check-if -operand-in-subsystem  (stmt  :  statement-obj)  = 

let  (subsystem  :  subsystem-obj  = 

least-ancestor-of-class(stmt,  * subsystem-obj)) 

if  operand (stmt)  'in  controllees (subsystem)  then 
Report-Error  (concat  ("Object  ",  symbol-to-string(operand(stmt)) , 

"  is  not  part  of  the  subsystem"),  subsystem) 

X - 

Check-If-Statement  —  Ensure  if  condition  is  veJ.id.  Then,  ensure  all 
%%  statements  in  then  and  else  clauses  are  OX. 

function  check-if-statement  (stmt  :  statement-obj)  = 

(if  get-oxpression-type(if-cond(stmt))  "=  'BOOLEAI  then 

Report-Error ("Invalid  condition  in  if  statement  ",  stmt) 

); 

(enumerate  stmtl  over  then-stmts (stmt)  do 
check-statement (stmt 1) 

): 

enumerate  stmt2  over  else-stmts(stmt)  do 
check-statement (stmt2) 

% - 

Vk  Check-Hhile-Statement  —  Ensure  uhile  condition  is  valid.  Then,  ensure  all 
%%  statements  in  shile  loop  are  OK. 

function  check-vhile-statement  (stmt  :  statement-obj)  = 

(if  get-ezpression-type(9hile-cond(stmt))  ~=  'BOOLEAI  then 

Report-Error ("Invalid  condition  in  while  statement  ",  stmt) 

); 
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enumerate  etmtl  over  vhile-stmts(stmt)  do 
check-statement (stmtl) 

XX  Check-SetFunction-Stmt  —  Ensures  that  lunction  name  specified  is  vsilid  for 
XX  the  statement’s  operand.  Then,  ensures  that  the  coefficients  specified 

XX  (if  any)  are  valid  for  that  operand. 

function  Check-SetFunction-Stmt  (stmt  :  statement-obj )  = 

if  object-ezists(operand(stmt))  then  Xchecks  meaningful  only  if  operand  exists 
check-f  or-val id-function-name (stmt ) ; 
check-for-valid-coefficients(stmt) 


function  Check-f or-Valid-Function-Iame  (stmt  :  statement-obj)  = 

XX  Thanks  to  Mary  Anne  Randour  for  the  essence  of  this  code 

let  (  oc  :  re::binding  =  instance-of (f ind-object( ’primitive-obj ,  operand (stmt)))) 
let  (func-name  :  symbol  = 

string-to-symbol  (concat(symbol-to-8tring(name(oc)) , 

symbol-to-string(function-name(stmt))) ,  "ru")) 
let  (valid-function  :  8et(object)  = 

{  X  I  (x;object)  re: ; vfunction-op(x)  k  size(re: :formals(x))  »  2  k 

name(re: :ref-to(re: :data-type(re: :formals(x)(2))))  =  name(oc)  k 
name(x)  =  func-name}) 

X  to  be  valid  function,  must  be  a  function,  must  have  tuo  parameters, 

X  the  type  of  the  second  parameter  must  be  an  object  of  the  same  class 
X  as  the  statement’s  operand  and  it  must  be  named  func-name  (uhich  is 
X  constructed  from  operand  object  class  and  specified  function  name) 

if  empty(v2ilid-function)  then 

Report-Error("Inv2^.id  function  name  in  setfunction  stmt",  stmt) 

function  Check-f or-V2^.id-Coefficients  (stmt  :  statement-obj)  = 

let  (obj  :  primitive-obj  =  find-object( ’primitive-obj ,  operand(stmt))) 
let  (obj-coefficients  :  set(name-value-obj)  = 

get-computed-attr-value(obj ,  ’ coefficients) ) 

XIOTE;  get-computed-attr-value  function  is  in  "execute"  file 

enumerate  coef  over  coefficients(stmt)  do 

let  (c  :  name-value-obj  = 

arb  ({c  I  (c  :  name-v2ilue-ob j )  name-value-obj (c)  k 

c  in  obj-coefficients  k  name-value-name (c)  =  name-value-name(coef)})) 

X  to  be  valid  coefficient,  there  must  be  a  name-v2d.ue-obj  in  the  operand’s 
X  coefficient  mapping  whose  name-value-name  =  coefficient  to  be  set 

if  undefined?(c)  then 

Report-Error(concat(" Illegal  coefficient  ", 


syinbol-to-string(name-valiie-naine(coel) )  ) ,  stmt) 


X - 

%%  Check-SetState-Stmt  —  Ensures  that  state  names  are  valid  lor  operand  and 
%%  if  so,  ensures  that  nev  value  is  compatible  vith  the  type  of  data  expected 
XX  lor  that  state  attribute. 

lunction  Check-SetState-Stmt  (stmt  :  statement-ob j )  = 

il  object-exist8(operand(stmt))  then  Xchecks  meaninglul  only  il  operand  exists 

let  (obj  :  primitive-obj  =  lind-object(’primitive-obj ,  operand(stmt))) 

let  (  oc  :  re: : binding  =  inatance-ol(lind-object{ 'primitive-obj ,  operand (stmt)))) 

*11 

enumerate  attr-to-set  over  8tate-changes(stmt)  do 
let  (attribute-name  :  symbol  = 

8tring-to-8ymbol  (concat(symbol-to-8tring(name(oc)) , 

8ymbol-to-string(name-V2G.ue-name(attr-to-set) ) ) ,  "ru") ) 
il  '(ex  (attr)  (attr  in  clas8-attributes(instance-ol(obj) ,  true)  * 
name(attr)  =  attribute-name))  then 
Report-ErrorC'Invalid  state  name  in  setstate  stmt”,  stmt) 

II* 


enumerate  attr-to-set  over  state-changes(8tmt)  do 
let  (attribute-name  :  symbol  = 

string-to-symbol  (concat(syBbol-to-string(name(oc)) , 

8ymbol-to-string(naffle-value-naffle (attr-to-set ) ) ) ,  "ru") ) 
let  (attr  :  re : : binding  = 

arb(-C  X  I  (x : re :: binding)  re:  :binding(x)  t 

X  in  class-attributes (instance-ol (obj ) ,  true)  * 
name(x)  =  attribute-name})) 

if  nndelined?(attr)  then 

Report-Error(concat("Invalid  state  name  (", 

symbol-to-string(name-value-name(attr-to-set)) , 

")  in  setstate  stmt"),  stmt) 

else 

XX  lorn  ensure  nev  value  is  ol  the  correct  type  lor  the  attribute  specilied 

let  (leg2Ll-type  :  symbol  =  get-attribute-type(attr) , 
valid-booleans  :  set(symbol)  =  {'t,  '1,  'T,  ’F}) 
lormat(t,  "legal-type  =  "s'X",  legal-type); 

il  legal-type  =  'integer  and  "integerp(name-value-value(attr-to-set))  then 
Report-Error (concat( "Value  provided  lor  ", 

8ymbol-to-8tring(name-value-name(attr-to-set) ) , 

"  is  not  integer  "),  attr-to-set) 

elseil  legal-type  =  'real  and  'lloatp(name-value-value (attr-to-set))  then 
Report-Error (concat ("Value  provided  lor  ", 

symbol-to-8tring(name-value-namo(attr-to-8et) ) , 

"  is  not  real  ") ,  attr-to-set) 
elseil  legal-type  =  'boolean  then 
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(if  name-valae-valuft(attr-to-set)  'in  veQ. id-bool eans  then 
Report-ErrorCconcatC'Value  provided  for  ", 

syiiibol-to-string(naiBe-value-naine(attr-to-set) ) , 

"  is  not  boolean  "),  attr-to-set) 

else 

set-attrs (attr-to-set ,  'name-value-value , 

convert-to-boolean(nama-value-value(attr-to-set) ) ) 

) 

elseif  legal-type  =  'string  and  'stringp(name-veG.ue-vaG.ue(attr-to-set))  then 
Report-Error (concat( "Value  provided  for  ", 

8ymbol-to-string(naffle-value-name(attr-to-set) ) , 

"  is  not  string  "),  attr-to-set) 

elseif  legal-type  =  'symbol  and  'symbolp(name-V2^.ue-value(attr-to-set))  then 
Report-Error(concat ("Value  provided  for  ", 

symbol-to-string(name-value-name(attr-to-set) ) , 

"  is  not  symbol  "),  attr-to-set) 


X - 

X - 

%%  Check-For-Exports-Corresponding-to-I^orts  —  Ensures  that  for  each  import-obj 
XX  in  the  subsystem's  import-area,  an  ezport-obj  exists  in  some  subsystem's 

XX  export  area  that  corresponds  to  it  (i.e.,  that  can  serve  as  the  source  of  the 

XX  external  data  needed) .  Generates  an  ERROR. . . 

XX  ffote:  the  import-obj  and  corresponding  ezport-obj  can  be  part  of  the  same 
XX  subsystem,  ill  subsystems  whose  export  areas  are  considered  for 
XX  "correspondence"  must  be  part  of  the  same  spec-obj  (in  case  there  is  more  than 
XX  one  in  the  object  base) 


function  Check-For-Exports-Corresponding-to-Ia^orts  (subsystem  :  subsystem-ob j )  = 

enumerate  import  over  import-area(subsystem)  do 
let  (exports  :  set (ezport-obj)  = 

<  export  I  (export: ezport-obj)  ezport-obj (export)  i 

export-category(export)  =  import -category (import)  i 
up-to-root(export)  =  up-to-root (import)}) 

if  empty(exports)  then 

Report-Error  (concat  ("lo  subsystem  produces  data  of  category  ”, 

symbol-to-8tring(import-category(import)) ,  "  for  object  ", 
symbol-to-8tring(consumer(import))) ,  subsystem) 

X - 

X - 

XX  Check-For-Dupes-in-Subsystem  —  ire  any  controllees  listed  more  than  once  in  the 
XX  same  subsystem?  If  so,  user  may  have  made  an  error  (most  likely  a  typo). 

XX  Generates  a  Warning . . . 
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function  Check-For-Dupes-in-Subsyatam  (subaystem  :  aubayatem-obj)  = 

let  (dup-controlleea  :  aeq(aymbol)  =  f ind-all-dupa  (controllaea(aubayatem}}) 

if  aize(dup-controlleea)  *=  0  than  %  Hava  dupaa  within  controllaaa  of  aingla  aubayatam 
anumarata  dupa  ovar  dup-controllaaa  do 

Raport-VamingCconcatC'Objact  ",  aymbol-to-8tring(dupa) , 

"  appaara  mora  than  onca  in  aubayatam").  aubayatam) 

% - 

X - 

Xy.  Chack-For-Unuaad-Componanta-in-Update  —  Ara  any  controllaaa  not  uaad  in  tha 
X  aubayatam  update  procedure?  If  any  ara  unuaed,  it  could  indicate  an  error 

XX  by  the  uaar  (either  a  typo  or  perhapa  ha  forgot  to  include  an  update 

XX  atatamant) .  Ganaratea  a  Warning... 


function  Check-For-Unuaad-Componenta-in-l^ate  (aubayatam  :  aubayatam-obj )  = 

let  (unuaad-componanta  :  8at(aymbol)  =  8eq-to-8at(controllaa8(8ub8y8tem))) 

(anumarata  atmt  ovar  updata(aub8y8tam)  do 
unuaad-componanta  <-  find-unu8ad-componanta(unuaad-componenta,  aubayatam,  atmt) 

); 

if  'empty (unuaad-componanta)  than 

anumarata  unuaed  ovar  unuaad-componanta  do 

Report-Warning  (concat  ("Component  ",  8ymbol-to-8tring(unu8ad) , 

"  not  uaad  in  aubayatam  update  procedure"),  aubayatam) 

X - 

X - 

X - 

XX  UTILITIES  —  Tha  following  functiona  perform  aoma  uaaful  taak  for  tha  varioua 
XX  aamantic  chacka... 

X - 

X - 

X - 

XX  Raaat-FATAL-ERROR  —  FATAL-ERROR  ia  global  variable  in  DM. 

XX  IF  FATAL-ERROR  ia  true,  a  aamantic  check  baa  found  an  error 

XX  which  muat  be  corrected  before  tha  aubayatam  can  be  executed. 

XX  For  teat  purpoaea,  it  ia  often  uaaful  to  be  able  to  ignore 
XX  thaaa  errora  by  raaatting  FATAL-ERROR 

rule  Raaat-FATAL-ERROR  (x:  object) 

FATAL-ERROR  ~> 

FATAL-ERROR  <-  falae 

X - 

X - 

XX  Report-Error  —  uaad  by  all  aamantic  chacka  to  diaplay  tha 
XX  error  to  tha  uaar ’a  acrean.  Naaaaga  ia  the  text  you  wiah 
XX  diaplayad  and  Obj  ia  tha  object  which  cauaad  tha  error 
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function  Report-Error  (Message:  string.  Obj:  object)  = 


formatCt,  "'XERROR  —  "s  "X",  Message); 
format (t,  "Object:  "WppW  "X'X",  Obj); 

FATAL-ERROR  <-  true 

- 

X - 

XX  Report-Vaming  —  used  by  some  semantic  checks  to  display  a 
XX  warning  to  the  user's  screen.  Message  is  the  text  you  wish 
XX  displayed  and  Obj  is  the  object  which  caused  the  error 
XX  Mote:  A  warning  indicates  something  may  be  wrong  with  the 
XX  specification  -  user  must  review  to  ensure  it  is  written  as 
XX  intended. 

function  Report-Warning  (Message:  string.  Obj:  object)  = 

format(t.  ""XMaming  —  "a  "X".  Message); 
format (t.  "Object:  "WppW  'X"X".Obj) 

% - 


% - 

function  Object-Exists  (Obj -lame  :  symbol)  :  boolean  = 

' (empty (  lame-Of (Obj -lame))) 

X - 

% - - - 

XX  f ind-all-dups  —  Given  a  sequence  of  any  type,  returns  another  sequence 
XX  which  contains  all  the. duplicates  found  in  the  original  sequence. 

XX  Each  duplicate  appears  only  once  in  the  returned  sequence  —  for  example 

XX  f ind-all-dups  on  [1,  2.  3.  2.  4,  1.  1]  returns  Cl.  2]. 

XX  Thanks  to  Dave  Zimmerman  of  Kestrel  Institute  for  this  code 

function  f ind-€J.l-dup8  (s;  seqCany-type)):  soq(any-type)  = 
let  (var  the-dups:  seq(any-type)  =  □) 

8  =  [. . .  X.  . . ,  y,  . .] 

A  X  =  y 

— >  X  in  the-dups; 
the-dups 

jj - 

X - 

function  find-unused-components  (unused-components  :  set (symbol), 

obj  :  component-ob j . 

stmt  :  statement-obj )  :  set (symbol) 

let  (component a -not -used  :  8et(symbol)  =  unused-components) 

(if  call-obj(8tmt)  then 

components-not-used  <-  components-not-used  less  operand(stmt) 
elseif  if-stmt-obj (stmt)  then 


D-34 


enumerate  stmtl  over  then-stmts(stmt)  do 

componente-not-used  <-  Xind-unused-components(components-not-u8ed,  obj ,  stmtl); 
enumerate  stmt2  over  else-stmts(stmt)  do 

components-not-used  <-  find-unused-componentsCcomponents-not-used,  obj,  stmt2) 

else 

enumerate  stmtl  over  uhile-stmts(stmt)  do 

components-not-used  <-  lind-unused-componentsCcomponents-not-used,  obj,  stmtl) 

); 

components-not-used 

X - 

% - 

%%  Get-Attribute-Type  —  returns  (as  a  symbol)  the  data  type  of  an  attribute 
%%  based  on  its  type  in  the  domain  model. 

%%  Thanks  to  Mary  Anne  Randour  for  this  code!! 

function  get-attribute-type  (attr  :  re:: binding)  :  symbol  = 

let  (  type-map  :  map(symbol,  symbol)  = 

{|  're: : symbol-op  ->  ’symbol, 

’re::real-op  ->  ’real, 

’re: : integer-op  ->  ’integer, 

’re: : boolean-op  ->  ’boolean, 

’re: :any-type-op  ->  ’any-type  |» 

let  (its-type  :  object  =  re: :range-type(re; :data-type(attr))) 

if  re: :cla88(its-type)  =  ’re: : binding-ref  then 
if  defined?(re: :bindingname(it8-type))  and-then 
re: :bindingname( its-type)  =  ’string  then 
’ string 
else 
’object 

else 

type-map(re: : class (its-type)) 

% - 

X - 

Convert-to-Boolean  —  transforms  a  symbol  to  boolean 

function  convert-to-boolean  (  symbol-to-convert  :  symbol)  :  boolean  = 

if  symbol-to-convert  =  ’t  or  symbol-to-convert  =  ’T  then 
true 

elseif  symbol-to-convert  =  ’f  or  symbol-to-convert  =  ’F  then 
false 

% - 
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D.6  Execute 


!!  in-package ("RU") 
!!  in-graomarC ’user) 


File  name:  execute. re 


% - 

%%  Oo-Execute  —  Used  to  simulate  execution  of  the  entire  application. 

Current  node  is  the  spec-obj  parsed  in  by  user.  Semantic  checks 
%%  must  have  already  been  performed  with  no  errors. 

rule  Do-Execute  (X  :  object) 

■fatal-error  k  semantic-checks-performed  — >  Find-and-Execute-Application(X) 
- 


% - 

XX  Find-and-Execute-Application  —  Finds  the  application-obj  vithin  the  current 
XX  application  (spec-obj)  and  calls  Execute-Application  to  execute  it. 

XX  ROTE:  There  is  only  one  application-obj  per  application  - 
XX  semantic  checks  insure  that. 

function  Find-and-Execute-Application  (x  :  object)  = 

semantic-checks-performed  <-  false;  X  reset  flag  to  force  semantic-checks  again 

let  (application  :  application-obj  = 

arb(-(a  I  (a:  application-obj)  application-obj  (a)  *  parent-expr(a)  =  x») 

Execute-Applicat ion(applicat ion) 


% - 

jr - 

XX  Execute-Application  —  Simulates  execution  of  an  application 
XX  (given  by  the  input  parmeter,  application)  by  enumerating 

XX  over  the  statements  in  the  application  update  procedure. 

XX  As  you  can  see,  this  is  virtually  identical  to  Execute-Subsystem. 

XX  Houever,  ve  are  currently  using  only  the  most  simple  application 

XX  executive.  In  the  future,  the  execution  of  applications  and  subsystems 

XX  may  be  vastly  different. 

function  Execute-Application  (  application  :  object)  = 

enumerate  stmt  over  applicatiou-update(application)  do 
execute-statement (application ,  stmt) 

% - 
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%• 

'm,  Execute-Subsystem  —  Simulates  execution  of  a  subsystem 
%%  (given  by  the  input  parmeter,  subsystem)  by  enumerating 

XX  over  the  statements  in  the  subsystem  update  procedure. 

function  Execute-Subsystem  (subsystem  :  object)  = 

enumerate  stmt  over  update (subsystem)  do 
execute-statement (subsystem,  stmt) 

X - 


- 

XX  Execute-Statement  —  Given  a  statement  from  a  subsystem  update 
XX  procedure,  calls  the  appropriate  function  to  execute  the 
XX  statement . 

function  Execute-Statement  (component  :  object, 

stmt  :  statement-obj)  = 

if  call-obj (stmt)  then  Do-Call-Stmt (component,  stmt) 
elseif  if-stmt-obj (stmt)  then  Do-If-Stmt(component,  stmt) 
elseif  «hile-stmt-obj(stmt)  then  Do-Hhile-Stmt( component,  stmt) 
else 

format(t,  "RUI-TIME  ERROR:  trying  to  execute  ”); 
format (t,  "an  invalid  statement:  "WppWX",  component) 

X - 


% - 

XX  Do-Call-Stmt  —  Executes  a  Call  statement.  Finds  the  object 
XX  referenced  as  the  operand  of  the  call  statement.  If  that  object 

XX  is  a  primitive-obj ,  call  the  correct  function.  If  the  operand  is 

XX  another  subsystem,  recursively  call  Execute-Subsystem. 

XX  Call-stmts  include  everything  but  if  and  while  statements . . . 

function  Do-Call-Stmt  (control:  object,  stmt  :  statement-obj)  = 

let  (obj  :  object  =  find-object( ’component-obj ,  operand(stmt))) 

if  defined? (obj)  then 

if  primitive-obj (obj)  then 
if  update-call-obj(stmt)  then 

X  call  the  current  update  function  name 
X  which  is  stored  in  object’s  update-function  attribute 
lisp: :funceJ.l(get-computed-attr-value(obj ,  ’UPDATE-FUICTIOH) , 
control,  obj) 

elseif  SetFunction-c!Ql-obj(stmt)  then 

SetFunction(operand(stmt) ,  function-name ( stmt ) ,  coeff icients(stmt)) 

elseif  SetState-call-obj(stmt)  then 

SetState( operand (stmt) ,  state-changes (stmt)) 
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else 

format (t,  "Erroneous  call  statement  for  a  primitive  object  'WppW'/,",  stmt) 

else  y,  operand  is  a  subsystem 
execute-subsystem(obj ) 

else  y.  The  object  referenced  by  the  opereuid  does  not  exist 

formatCt,  "RUH-TIME  ERROR:  trying  to  execute  a  statement  ") ; 
format(t,  "with  a  non-existent  operand  "WppW"*/,",  stmt) 
y, - 


% - 

y,y,  Do-If-Stmt  —  Executes  an  If  statement.  If  if-cond  evaluates  to 
y,y,  true,  ceG.1  Execute-Statement  for  each  of  the  statements  in 
y,y,  then-stmts.  If  if-cond  is  false,  call  Execute-Statement  for 
y,y,  each  statement  in  else-stmts. 

function  Do-If-Stmt  (control:  object,  stmt  :  statement-obj)  = 

if  ev2Lluate-boolean-expression(if-cond(stmt))  then 
enumerate  then-stmt  over  then-stmts(stmt)  do 
execute-statement (control ,  then-stmt) 

else 

enumerate  else-stmt  over  else-stmts (stmt)  do 
execute-statement (control,  else-stmt) 

% - 


y, - 

yH,  Do-While-Stmt  —  As  long  as  the  while-cond  evaluates  to  true, 
yH,  call  Execute-Statement  for  each  statement  in  while-stmts. 

function  Do-While-Stmt  (control:  object,  stmt  :  statement-obj)  = 

while  evaluate-boolean-expression(while-cond(stmt))  do 
enumerate  while-stmt  over  while-stmts(stmt)  do 
execute-statement(control ,  while-stmt) 

51 - 


5f - 

y,y,  SetFunction  —  Only  valid  for  primitive  objects.  Sets  the  object’s  update 
yH,  function  name  and  any  coefficients  that  are  also  provided.  Coefficients 
yX  to  be  set  must  already  exist. 

function  SetFunction  (operand-name  :  symbol, 

function-name  :  symbol, 

coeff icients-to-set  :  set (neune-value-obj ) )  = 

format  (debug-on,  "Calling  SetFunction  on  primitive  object  "s'*/,",  operand-name); 

let  (obj  :  primitive-obj  =  find-object(’primitive-obj ,  operand-name)) 


D-38 


let  (oc  :  re::biiiding  =  instance-ol (obj)) 
let  (new-function-name  :  symbol  = 

string-to-symbol(concat(symbol-to-string(name(oc) ) ,  , 

sjfmbol-to-string(lunction-name)) ,  "ni")) 

VU  The  above  "let"  statements  are  needed  to  complete  the  full  function  name. 

%%  The  object  class  must  be  appended  to  the  function  nctme  provided  by  the  user. 

set-computed-attr  (obj,  ’update-function,  nev-function-name) ; 

*/,7.  low  set  the  coefficients... 

let  (obj -coefficients  :  set(name-value-obj)  = 

get-computed-attr-value(obj ,  ’coefficients)) 

enumerate  coef  over  coeff icients-to-set  do 

let  (c  :  name-value-obj  = 

arb  ({c  1  (c  :  name-value-obj)  name-value-obj (c)  k 

c  in  obj -coefficients  k  name-V2J.ue-name(c)  =  name-value-name(coef )») 

if  undef ined?(c)  then 

format(t,  "RUH-TIME  ERROR:  Coefficient  "s  does  not  exist'X", 
name-value-name ( coef ) ) 

else 

obj -coeff icients  <-  obj -coefficients  less  c; 
obj-coefficients  <-  obj-coeff icients  srith  coef; 
set-computed-attr  (obj,  ’coefficients,  obj-coefficients) 


% - 

y,'/,  SetState  —  Only  valid  for  primitive  objects.  For  each  item  in 
y,%  state-changes-to-mahe  (statement’s  state-changes),  set  the 
%%  appropriate  attribute  of  the  operand  to  the  given  value. 

function  SetState  (operand-name  :  symbol, 

state-changes-to-make  :  set(n2UDe-value-obj))  = 

lot  (obj  :  primitivo-obj  =  f ind-objoct(’primitive-obj ,  operand-name)) 

format  (debug-on,  ""y.Calling  SetState  on  primitive  object  "WppW'JC,  obj); 


•/. 


enumerate  state-change  over  state-changes-to-m2dce  do 

set-computed-attr  (obj ,  name-value-name(state-change) , 

name-value-value(state-cbange)) 


•/.- 

%- 

•/:/. 

y.- 


Utilities 


D-39 


The  following  functions  are  "utilities”  used  to  retrieve  data 
y.'/,  from  an  attribute  whose  name  must  be  constructed  and  to  store 
%%  data  to  such  an  attribute. 

% - 

%%  Get-Computed-Attr-Value  —  appends  partial-attr-name  after 
%y,  obj’s  object-class  name  (a  symbol,  which  is  obtained  by  using 
y,y,  REFIHE’s  instance-of  function)  to  determine  attribute  name. 

V/t  Use  the  REFINE  fiuction,  retrieve-attribute,  to  get  the  current 

Vh  value  stored  in  that  attribute  and  return  it  to  the  calling  function. 

function  get-computed-attr-v2G.ue  (obj  :  primitive-obj , 

partial-attr-name  :  symbol  )  :  any-type  = 

let  (  oc  :  re::binding  =  instance-of (obj)) 
let  (var-name  :  symbol  = 

string-to-symbol  (concat(symbol-to-string(name(oc)) , 

aymbol-to-string(partial-attr-name) ) ,  "ru") ) 
retrieve-attribute (obj ,  f ind-attribute(var-name)) 

X - 


X - 

y,y.  Set-Computed-Attr  —  appends  partial-attr-name  after  obj’s 
XX  object-class  name  (a  symbol,  which  is  obtained  by  using 
XX  REFINE ’8  instance-of  function)  to  determine  the  attribute  name 
XX  (var-name).  Use  REFINE’S  store-attribute  function  set  the 
XX  current  value  of  attribute  referenced  by  var-name  to  new-value. 

function  set-computed-attr  (obj  ;  primitive-obj , 

partial-attr-name  :  symbol, 
new-value  :  any-type)  = 


let(  oc  :  re;:binding  =  instance-of (obj)) 
let (var-name  :  symbol  = 

string-to-symbol  (concat(symbol-to-string(name(oc)) , 
symbol-to-string(partial-attr-name) ) ,  "ru") ) 
store-attribute (obj ,  find-attribute (v^lr-name) ,  new-value) 


- 

XX  Get-Coefficient-Value  —  Used  by  primitive  object  update  functions  to 
XX  obtain  the  current  value  of  the  coefficient  given  by  coefficient-name. 

function  get-coefficient-value  (obj  ;  primitive-obj, 

coefficient -name  :  symbol)  :  any-type  = 

let  (obj-coefficients  :  set(name-value-obj)  = 

get-computed-attr-value(obj ,  ’coefficients) ) 
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let  (c  :  name-value-obj  = 

arb  ({c  I  (c  :  name-value-obj)  name-value-obj (c)  ft 

c  in  obj-coellicients  ft  name-value-name (c)  =  coelf icient-name})) 

name- value- value ( c ) 

X - 


D.  7  Eval-Expr 

! !  in-package ("RO") 

!!  in-grammarC ’user) 

%%  file:  eveJ.-eipr .  re 

%'/•  NOTE:  This  code  eas  taken  almost  verbatim  from  our  final  project 
in  CSCE  663 .  This  is  another  example  of  code  reuse . . . 


y.%  Evaluate-Boolean-Expression  —  returns  the  value  of  the 
%  given  boolean  expression.  If  it’s  a  boolean  litereG.,  return 
X  its  value;  if  an  identifier,  retrieve  its  value  (identifiers 

%  are  linked  to  an  import-obj  or  export-obj  as  determined  by  the 

X  application  specialist):  otherwise,  evaluate  argumentl  and 
X  argument2  separately  and  perform  the  appropriate  operation  on 

X  them. 

function  Evaluate-Boolean-Expression  (X:  Object)  :  Boolean  = 

format  (debug-on,  "in  evaluate  boolean  exp,  object  =  "WppW  "X",  x); 
if  True-Literal (X)  then 
true 

elseif  False-Literal (X)  then 
fzG-se 

elseif  Identif ier(X)  then 

Get-Id-Value-for-Conditional(X)  X  function  located  in  imports-exports 

elseif  Equal-Exp(X)  then 

let  (Exp-Type  :  symbol  =  ’IITEGER) 

(if  Identifier(Argumentl(X))  then 
Exp-Type  <-  Get-Id-Type-for-Conditional(Argumentl(X)) 
else  X  must  be  an  object 
Exp-Type  <-  Get-Expression-Type(Argumentl(X)) 

); 

(if  Exp-Type  =  ’IITEGER  then 
Evaluate-Integer-Expression(Argumentl(X))  = 

Evaluat  e- Int  eger-Expres  s ion ( Argument  2 ( X ) ) 
elseif  Exp-Type  =  ’BOOLEAI  then 
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EveJ.uate-Boolean-Ezpression(  Argument  1  (X)  )  = 

Evaluat e-Boolean-Ezpress ion ( Argafflent2 ( 1} ) 
elseil  Exp-Type  =  ’STRUG  then 
Evaluat  e-St  r ing-Expr es s ion ( Argument 1(1))  = 

Evaluat e-Str ing-Expr ess ion( Argument2 ( X ) ) 
else  %  Exp-Type  must  be  real 
Ev2J.uate-Real-Expression(Argumentl(X) )  = 
Evaluate-Real-Expression(Argument2(X)) 

) 

elseif  LT-Exp(X)  then 

let  (Exp-Type  :  symbol  =  ’IITEGER) 

(if  Identifier(Argumentl(X))  then 

Exp-Type  <-  Get-I<i-Type-for-Conditional(Argumentl(X)) 
else  %  must  be  an  object 

Exp-Type  <-  Get-Expression-T3rpe(Argumentl(X)) 

); 

(if  Exp-Type  =  ’IITEGER  then 
Evaluat  a- Int eger-Expr es  s ion ( Argument 1 ( X ) )  < 

Evaluate-Integer-Expression(Argument2 (X) ) 
elseif  Exp-T3rpe  =  ’STRUG  then 
Evaluate-String-Express ion( Argument 1 (X) )  < 

Ev2Lluate-String-Expression( Argument2 (X) ) 
else  %  Exp-Type  must  be  resO. 
Evaluate-Real-Expression(Argumentl (X) )  < 

Evaluat  e-Real-Expres  sion (Argument 2 (X ) ) 

) 

elseif  LTE-Exp(X)  then 

let  (Exp-Type  :  symbol  =  ’IITEGER) 

(if  Identif ier(Argumentl(X))  then 
Exp-Type  <-  Get-Id-Type-for-Conditionsd(Argumentl(X)) 
else  */.  must  be  an  object 

Exp-Type  <-  Get-Expression-Type(Argumentl(X)) 

); 

(if  Exp-Type  =  ’IITEGER  then 
Evaluate-Integer-Expression(Argumentl(X) )  <= 
Ev2d.uate-Integer-Expression(Argufflent2(X)) 
elseif  Exp-Type  =  ’STRUG  then 
Evaluate-String-Expre8sion(Argnment 1 (X) )  < 

Ev2J.uate-String-Expression(Argument2 (X) ) 
else  %  Exp-Type  must  be  real 
Evaluate-Real-Expression(Argumentl(X) )  <= 

Evaluat  e-Real-Expr es  s ion ( Argument2 (X ) ) 

) 

elseif  GT-Exp(X)  then 

let  (Exp-Type  :  symbol  =  ’IITEGER) 

(if  Identifier(Argumentl(X))  then 
Exp-Type  <-  Get-Id-Type-for-Conditional(Argumentl(X)) 
else  %  must  be  an  object 

Exp-Type  <-  Get-Expression-Type (Argument 1(X)) 

): 
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(if  Exp-Type  =  ’IHTE6ER  then 

Evalttate-Integer-Expression(Argamentl (X) )  > 
Evaluate-Integer-Expression(Argumeiit2 (X) ) 
elseil  Exp-Type  =  ’STRUG  then 
Evaluat e-Str ing-Expres s ion ( Argument 1 (X) )  < 

Evaluate-String-Expression(Argument2 (X) ) 
else  %  Exp-Type  must  be  rezJ. 
Evaluate-Real-Expression(Argumentl(X))  > 

Eved.uat  e-Real-Expr  ess  ion  (  Argument2  (X  ) ) 

) 

elseiX  GTE-Exp(X)  then 

let  (Exp-Type  :  symbol  =  ’IITEGER) 

(if  Identifier(Argumentl(X))  then 
Exp-Type  <-  Get-Id-Type-lor-ConditionaQ.(Argumentl(X)) 
else  X  must  be  an  object 

Exp-Type  <-  Get-Expression-Type(Argumentl(X)) 

): 

(if  Exp-Type  =  ’IITEGER  then 
Evaluat  e-Znt  eger-Expr es  s ion ( Argument 1 ( X ) )  >= 
Evaluate-Integer-Expression(Argument2 (X) ) 
elseif  Exp-Type  a  ’STRUG  then 
Evaluate-String-Expression( Argument 1 (X) )  < 

Evaluate-Str ing-Expression (Argament2 (X) ) 
else  X  Exp-T3rpe  must  be  real 
Evaluate-Real-Expression(Argumentl(X} )  >s 
Evaluate-Real-Expres8ion(Argument2(X)) 

) 

elseif  And-Exp(X)  then 

Evaluate-Boolean-Expression(Argumentl(X) }  A 
Ev2Q.uate-Boolean-Expres3ion(Argument2  (X)  ) 

elseif  Or-Exp(X)  then 

Evaluat e-Boolean-Expr ess ion (Argument 1 (X ) )  or 
Evaluat  e-Boolean-Expr ess ion ( Argument2 (X) ) 

elseif  lot-Exp(X)  then 

not  (Evaluate-Boolean-Expres8ion(Argument (X) ) ) 


- 

XX  Evaluate-Integer-Expression  —  returns  the  value  of  the 
X  given  integer  expression.  If  it’s  a  literal. ,  return 
X  its  value;  if  an  identifier,  retrieve  its  value  (identifiers 

X  are  linked  to  em  import-obj  or  export-obj  as  determined  by  the 

X  application  specialist);  otherwise,  evaluate  argumentl  and 
X  argument2  separately  and  perform  the  appropriate  operation  on 

X  them. 
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function  Evaluate-Integer-Expression  (X  ;  Expression)  :  integer  = 

format  (debug-on,  "in  evaluate  integer  exp,  object  =  "\\pp\\  x); 

if  Integer-Literal (X)  then 
Int-Value(X) 

elseif  Identif ier(X)  then 

Get-Id-Value-for-Conditionad-CX)  %  function  located  in  imports-exports 

elseif  add-exp(X)  then 

(Evaluate-Integer-ExpressionCArgumentl (X) ) 
Evaluate-Integer-Expression(Argument2(X) ) ) 

elseif  Subtract-Exp (X)  then 

Evaluate-Integer-Expression(Argumentl(X) )  - 
Evaluate- Integer-Expre8sion(Argument2(X)) 

elseif  Multiply-Exp(X)  then 

Ev2Quate-Integer-Expre8aion(Argumentl(X))  * 

Evaluat  e-Int  eger-Expres  s ion ( Argument2 (X) ) 

elseif  Oivide-Exp(X)  then 
Evaluat e-Integer-Expression (Argument 1 (X) }  div 
Evaluate- Integer-Expression(Argument2(X)) 

elseif  Nod-Exp(X)  then 

Evaluat e-Int eger-Expr ess ion (Argument i (X ) )  mod 
Evaluat  e-Int  eger-Expr e s  s ion ( Argument 2 ( X ) ) 

elseif  Ab8-Exp(X)  then 

let  (Exp-Value  :  integer  =  0) 

Exp-Value  <-  Evaluate-Integer-Expression  ( Argument 1 ( X) ) ; 
if  Exp-Value  <  0  then 
0  -  Exp-Value 
else 

Exp-Value 

elseif  legate-Exp(X)  then 

let  (Exp-Value  :  integer  =  0) 

Exp-Value  <-  Evaluate-Integer-Expression  (Argument (X) } ; 

0  -  Exp- Value 

elseif  Posit ive-Exp(X)  then 

let  (Exp-Value  :  integer  =  0) 

Exp-Value  <-  Evaluate-Integer-Expression  (Argument (X) ) ; 

Exp-Value 

%  Refine  does  not  handle  exponentiation 
elseif  Exponential-Exp(X)  then 
let  (Poser  :  integer  =  1, 
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Base  :  integer  =  Evaluate-Integer-Expression(Argumentl(X)) , 

Ezpon  :  integer  =  ETaluate-Integer-Erpression(ArgnBent2(X))) 

(entiBerate  index  from  1  to  Expon  do 
Pover  <-  Poser  *  Base  ) ; 

Poser 

else 

tomat  (debng-on , 

“Trying  to  evaluate  a  non-integer  Innction  as  an  integer  *%"); 
foraat (debng-on,  "Object  =  "WppW  *%",  X); 

0 

% - 

% - 

X%  Evalnate-String-E^^ression  —  returns  the  value  of  the 
X  given  string  expression.  If  it’s  a  literal,  return 
X  its  value;  il  an  identifier,  retrieve  its  value  (identifiers 

X  are  linked  to  an  iaport-obj  or  export-obj  as  deterained  by  the 

X  application  specialist) .  This  inplenentation  currently  alloss 
X  no  operations  on  strings  sithin  expressions. 

function  Evaluate-String-Expression  (X:  Object)  :  String  = 

format (debug-on,  "in  evaluate  string  exp,  object  =  *\\pp\\  *X",  x); 

if  String-Literal (X)  then 
String- Value (X) 

else  X  X  is  an  Identifier 

Get-Id-Value-for-Conditional(X)  X  function  located  in  imports-exports 
X - 

X - 

XX  Evaluate-Real-Expressiou  —  returns  the  value  of  the 
X  given  real  expression.  If  it's  al  iteral,  return 
X  its  value;  if  an  identifier,  retrieve  its  value  (identifiers 

X  are  linked  to  an  import-obj  or  export-obj  as  determined  by  the 

X  application  specialist);  othervise,  evaluate  argumentl  and 
X  argument2  separately  and  perform  the  appropriate  operation  on 

X  them. 

function  Evaluate-Real-Expression  (X:  Object)  :  Real  = 

format  (debug-on,  "in  evaluate  real  exp,  object  =  "WppW  "X",  x); 

if  ReaQ -Literal (X)  then 
Real-Value(X) 

elseif  Identif ier(X)  then 

Get-Id-Value-for-Conditional(X)  X  function  located  in  imports-exports 
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elsail  add-ezp(X)  then 

(Evaluate-Real-Ezpressiondrgunentl (X) ) 
Eveduate-Real-Expression(Argiiment2(X) ) ) 

elseif  Sabtract-Ezp(X)  then 

Evaluate-Re2G.-Ezpression( Argument  1  (X) )  - 
Evaluate-Real-Ezpression ( Argament2 (X) ) 

elseif  Naltiply-Ezp(X)  then 

Evaluate-Real-Ezpres8ion( Argumentl (X) )  * 
EvaQ.uate-Resil-Ezpreasion(Argument2(X)  ) 

eleeif  Divide-Exp(X)  then 
Evaluate-Real-EzpreseionCArgomentl (X) )  / 
Evaluate-Real-Ezpression(Argument2(X)) 

elseif  legate-Ezp(X)  then 
let  (Exp-Value  :  real  =0.0) 

Exp-Value  <-  Evalnate-Real -Expression  (Argument (X) ) ; 

0.0  -  Exp-Value 

elseif  Exponential-Exp(X)  then 
let  (Pomer  :  real  =  1.0, 

Base  :  re«d  =  Evaluate-Real-Expres8ion(Argnmentl(X)) , 

Expon  :  integer  =  ETaluate-Integer-Expression(Argument2(X))) 

(enumerate  index  from  1  to  Expon  do 
Poser  <-  Poser  ♦  Base  ); 

Poser 

elseif  Ab8-Exp(X)  then 

let  (Exp-Value  ;  real  =  0.0) 

Exp-Value  <-  Evaluate-Real-Expression  ( Argument 1 (X) ) ; 
if  Exp-Value  <0.0  then 
0.0  -  Exp-Value 
else 

Exp-Vzdue 

else 

format (debug-on,  "Trying  to  evaluate  a  non-reiJ.  function  as  a  real  "%"); 
format  (debug-on,  "Object  =  "WppW  X); 

0.0 

% - 

X - 

X  utilities 

X - 


function  Report-Type-Nismatch-Error(X: object,  left, right  :  symbol.  Message:  string)  = 
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foraatCt,  "Error  —  Type  Mismatch  in  expression  —  's  Message); 
lormatCt,  "Object:  'WppW  X); 

lormatCt,  "LHS  type  is  ‘s  symbol-to-string(lelt)); 

if  right  '=  'nil  then 

format(t,  "RHS  type  is  *s  symbol-to-string{right)) 


X - 

X - 

X%  Get-Expression-Type  —  Returns  the  type  of  an  expression  (as  a  symbol) . 
XX  If  it  finds  a  mismatch,  it  reports  an  error  to  the  calling  function. 

function  Get-Expression-Type  (X  :  object)  :  symbol  = 


if  Integer-Literal (X)  then 
'IITEGER 

elseif  Real-Literal (X)  then 
'REAL 

elseif  Boolean-Literal (X)  then 
'BOOLEAl 

elseif  String-Literal (X)  then 
'STRUG 

elseif  Identif ier(X)  then 

Get-Id-Type-for-Conditional(X)  X  returns  type  of  data  to  mhich 

X  id  refers  or  ERROR  if  no  id-source 
X  is  specified 

X  for  *,  *,  and  /,  both  left  and  right  sides  must  be  the  same  type 

elseif  add-exp(X)  or  subtract-exp(X)  or  multiply-exp(X)  or  divide-exp(X)  then 
let  (left-type  :  symbol  =  Get-Expression-Type(argumentl(x)) , 
rt-type  :  symbol  =  Get-Expression-Type(argument2(X))  ) 
if  (left-type  =  rt-type)  and  (left-type  "=  'ERROR  and  rt-type  "=  'ERROR)  then 
left-type 
else 

Report-Type-Misnatch-Error(X, left-type,  rt-type,  "Types  must  match"); 

'ERROR  X  return  error 

X  for  nod,  both  must  be  integers 
elseif  mod-exp(X)  then 

let  (left-type  :  symbol  =  Get-Expre8sion-Type(argumentl(X)) , 
rt-type  :  symbol  =  Get-Expression-Type(eLrgument2(X))  ) 
if  left-type  =  'IITEGER  and  rt-type  =  'IITEGER  and 

(left-type  '=  'ERROR  and  rt-type  "=  'ERROR)  then 

left-type 

else 

Report-Type-Mi8natch-Error(X,left-type,  rt-type,  "Both  sides  must  be  integers") 
'ERROR  X  return  error 

X  for  **,  left  side  can  be  integer  or  real,  right  side  must  be  integer. 
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alssil  ezponential-ezp(X)  then 

let  (left-type  :  symbol  =  Get-Ezpression-Type(argumentl(X)) , 
rt-type  :  symbol  =  Get-Ezpression-Type(argument2(X))  ) 
if  (left-type  =  ’IITEGER  or  left-type  =  ’REAL)  and  rt-type  =  'IITEGER 
and  (left-type  "=  'ERROR  and  rt-type  "=  ’ERROR)  then 
left-type 
else 

Report-Type-Mismatch-Error (X , left-type ,  rt-type , 

"Left  side  must  be  integer  or  real  and  right  side  must  be  an  integer"); 
’ERROR  %  return  error 

)■  for  abs,  argument  cannot  be  boolean 
elseif  Abs-Ezp(X)  then 

let  (Ezp-Type  :  symbol  =  Get-Ezpression-Type(Argument(X))  ) 
if  Ezp-Type  '=  'BOOLEAV  and  Ezp-Type  *=  ’STRUG  then 
Ezp-Type 
else 

Report-Type-Mismatch-Error (X,  Ezp-Type,  ’nil, 

"Type  must  not  be  boolean  or  string"); 

’ERROR  X  return  error 

X  for  unary  minus,  argument  cannot  be  boolean 
elseif  legate-Ezp(X)  then 

let  (Ezp-T3rpe  :  symbol  =  Get-Ezpression-Type (Argument (X))  ) 
if  Ezp-Type  *=  ’BOOLEAI  and  Ezp-Type  '=  ’STRIHG  then 
Ezp-Type 
else 

Report-Type-Mismatch-Error (X,  Ezp-Type,  ’nil, 

"Type  must  not  be  boolean  or  string"); 

’ERROR  X  return  error 

X  for  unary  plus,  argument  cannot  be  boolean 
elseif  Po8itive-Ezp(X)  then 

let  (Ezp-Type  :  symbol  =  Get-Ezpression-Type(Argument(X))  ) 
if  Ezp-Type  "=  'BOOLEAI  and  Ezp-Type  '=  'STRUG  then 
Ezp-Type 

else 

Report-Type-Mi8match-Error(X,  Ezp-Type,  'nil, 

"Type  must  not  be  boolean  or  string"); 

'ERROR  X  return  error 


X  all  relation  operators,  both  arguments  must  be  the  same  type 
elseif  Equal-Ezp(X)  or  lot-Equal-Ezp(X)  or  LT-Ezp(X)  or  LTE-Ezp(X)  or 
GT-Ezp(X)  or  GTE-Ezp(X)  then 

let  (left-type  ;  symbol  =  Get-Ezpression-Type(argumentl(X)) , 
rt-type  :  symbol  =  Get-Ezpression-Type(argument2(X))  ) 
if  left-type  =  rt-type  and  (left-type  *=  'ERROR  and  rt-type  *=  ’ERROR)  then 
'BOOLEAI 

else 

Report-Type-Mismatch-Error(X, left-type,  rt-type,  "Types  must  match"); 
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’ERROR  X  return  error 

X  lor  and,  or  both  arguments  must  be  booleans 
elseil  ind-Exp(X)  or  Or-Ezp(X)  then 
let  (lelt-type  ;  symbol  =  Get-Expression-Type(argumentl(X)) , 
rt-type  :  symbol  =  Get-Expression-Type(argument2(X))  ) 
if  lelt-t3rpe  =  ’BOOLEAI  and  rt-type  =  'BOOLEAI 

and  (lelt-type  "=  'ERROR  and  rt-type  '=  'ERROR)  then 

'BOOLEAI 

else 

Report-Type-Mismatch-Error (X, left-type,  rt-t3^e,  "Both  sides  must  be  booleans"); 
'ERROR  X  return  error 

X  for  not,  argument  must  be  boolean 
elseif  lot-Exp(X)  then 

let  (Exp-Type  :  symbol  =  Get-Expression-Type(Argument(X))  ) 
if  Exp-Type  =  'BOOLEAI  then 
Exp-Type 
else 

Report-Type-Mismatch-Error(X,  Exp-Type,  'nil,  "Type  must  be  boolean"); 

'ERROR  X  return  error 


else 

format (debug-on , 

"You  shouldn't  be  calling  this  procedure  with  this  object!  !*'/."); 
format  (debug-on,  "Object  =  'WppW  "X",  x) 
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Appendix  E.  Technology  Base  for  the  Logic  Circuit  Domain 


This  appendix  contains  the  REFINE  code  for  the  logic  circuit  technology  based  used 
in  the  logic  circuit  domain  used  to  validate  Architect.  Each  section  defines  a  single  primitive 
object  within  the  domain.  Please  note  the  conformance  to  the  primitive  object  template 
described  in  Appendix  A. 


E.l  And-Gate 


J!  in-package ("RU") 
M  in-graiBm2u:( ’user) 


y.%  File  name:  and-gate.re 

var  AID-GATE-OBJ  ;  object-class  subt3fpe-of  Primitivo-Obj 

var  AID-GATE-OBJ-IIPUT-DATA  :  set(import-obj)  = 
fset-attrs  (make-ob j ect ( ’ import-ob j ) , 

’ import-name ,  * ini , 

’import-category,  ’signal, 

’  import-tjrpe-data,  ’boolean) , 

set-attrs  (make-ob j  ect ( ’ import-obj ) , 

’import-name,  ’in2, 

’import-category,  'sign^□., 

’ import -type-data,  ’boolean)} 

var  AID-GATE-OBJ-OUTPUT-DATA  :  set(export-obj)  = 
f set-attrs  (make-ob j  ect ( ’ eiport-obj ) , 

’ export-name ,  ’ outl , 

’export-category,  ’signal, 

’ export -type-data ,  ’boolean) } 

var  AID-GATE-OBJ-COEFFICIEITS  :  map(AID-GATE-OBJ,  set(name-value-obj)) 
comput  ed-us ing 

AID-GATE-OBJ-COEFFICIEITS (x)  =  {} 


var  AID-GATE-OBJ-OPDATE-FUICTIOI  :  map(AID-GATE-OBJ,  symbol) 
computed-using 

AID-GATE-OBJ-UPDATE-FUICTIOI(x)  =  ’AID-GATE-OBJ-UPDATEl 
y,  Other  Attributes: 

var  AID-GATE-OBJ-DELAY  :  map(AID-GATE-OBJ,  integer) 
comput  ed-us  ing 
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AID-GATE-OBJ-DELAY(x)  =  0 


var  ABD-GATE-OBJ-MAIUFACTURER  :  map(AID-GATE-OBJ ,  string) 
comput  ed-us  ing 

AMD-GATE-OBJ-MAIUFACTURER(x)  =  “  " 

var  AID-GATE-OBJ-MIL-SPEC?  :  map(AID-GATE-OBJ,  boolean) 
comput  ed-us ing 

AID-GATE-OBJ-MIL-SPEC? (x)  =  nil 

var  AHD-GATE-OBJ-POWER-LEVEL  :  map(AID-GATE-OBJ,  real) 
comput  ed-us  ing 

AID-GATE-OBJ-POWER-LEVEL(x)  =0.0 

form  Make-AlD-GATE-lames-Unique 
unique-namas-class( ’AID-GATE-OBJ ,  true) 


54 - 

function  AID-GATE-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

and-gate  :  AID-GATE-OBJ)  = 

format (debug-on,  "AID-GATE-OBJ-UPDATE  on  "s'X",  name(and-gate)) ; 

let  (ini  :  boolean  =  get-import (' ini ,  subsystem,  and-gate), 
in2  :  boolean  =  get-import ('in2,  subsystem,  and-gate)) 

set-export (subsystem,  and-gate,  'outl,  ini  ft  in2) 

5j - 

function  AlO-GATE-OBJ-HEV-UPDATE  (subsystem  :  subsystem-obj , 

and-gate  :  AID-GATE-OBJ)  = 

format (t,  "AID-GATE-OBJ-IEW-UPDATE  on  "s"%”,  name(and-gate)) 


E.2  Or-Gate 

M  in-package ("RU”) 
!!  in-grammar('user) 


%y.  File  name:  or-gate.re 

var  OR-GATE-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  OR-GATE-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{set-attrs  (make-ob j  ect ( ’ import -obj ) , 

’ import -name ,  ’ ini , 

’ import-cat  egory ,  ’ s ignal , 
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’import-type-data,  ’boolean), 


set-attrs  (make-object( ’import -obj) , 

’ import -name ,  ’ in2 , 

’import-category,  ’signcil, 

’import-type-data,  ’booleem)} 

var  OR-GATE-OBJ-OUTPUT-DATA  :  set(export-obj)  = 

{set-attrs  (make-object ( ’export-obj) , 

’export-name,  ’outl, 

’export-category,  ’signal, 

’ export -type-data,  ’boolean)} 

veu:  OR-GATE-OBJ-COEFFICIEITS  :  map(OR-GATE-OBJ,  set(name-valne-obj)) 
comput  ed-us ing 

OR-GATE-OBJ-CQEFFICIEITS(x)  =  {} 


var  OR-GATE-OBJ-UPDATE-FUICTIQH  :  map(OR-GATE-OBJ,  symbol) 
comput  ed-us ing 

OR-GATE-OBJ-UPDATE-FOTCTIOMCx)  =  'OR-GATE-OBJ-UPDATEl 
%  Other  Attributes: 

var  OR-GATE-OBJ-DELAY  :  map(OR-GATE-OBJ,  integer) 
comput  ed-us ing 
OR-GATE-OBJ-DELAY(x)  =  0 

var  OR-GATE-OBJ-MAIUFACTURER  :  map(OR-GATE-OBJ,  string) 
comput  ed-us  ing 

OR-GATE-OBJ-MAIUFACTURER(x)  =  "  " 

var  OR-GATE-OBJ-MIL-SPEC?  :  map(OR-GATE-OBJ,  boolean) 
comput  ed-us  ing 

OR-GATE-OBJ-MIL-SPEC? (x)  =  nil 

var  OR-GATE-OBJ-POWER-LEVEL  :  map(OR-GATE-OBJ,  real) 
comput  ed-us ing 

OR-GATE-OBJ-POWER-LEVEL(x)  =0.0 

form  Nake-OR-GATE-Iames-Unique 
unique-names-class( ’OR-GATE-OBJ,  true) 

- 

function  OR-GATE-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

or-gate  :  OR-GATE-OBJ)  = 

format (debug-on,  "OR-GATE-OBJ-UPDATE  on  name (or-gate) ) ; 

let  (ini  ;  boolean  =  get-import (’ini,  subsystem,  or-gate), 
in2  ;  boolean  =  got-import( ’in2,  subsystem,  or-gate)) 

set-export (subsystem,  or-gate,  ’outl,  (ini  or  in2)) 
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^ - 

function  OR-GATE-OBJ-HEW-UPDATE  (subsystem  :  subsystem-obj , 

or-gate  :  OR-GATE-OBJ)  = 


format(t,  "OR-GATE-OBJ-HEH-UPDATE  on  's-/.",  name  (or-gate)) 


E.3  Nand-Gate 


M  in-package ("RU") 
!!  in-grammar ( ’user) 


V,Vt  File  name:  nand-gate . re 

var  HAID-GATE-QBJ  :  object-class  subtype-of  Primitive-Obj 

var  lASD-GATE-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{set-attrs  (make-ob j  ect ( ’ import-obj ) , 

’ import -name ,  ’ ini , 

’import-category,  ’signal, 

’  import-t]fpe-data,  ’boolean) , 

set-attrs  (make-objact( ’ import-obj) , 

’import -name,  ’in2, 

’import-category,  ’signal, 

’import -type-data,  ’boolean)} 

var  HAID-GATE-OBJ-OUTPUT-DATA  :  set(export-obj)  = 

{set-attrs  (make-ob j  ect ( ’ export-obj ) , 

’export-name,  ’outl, 

’export-category,  ’signal, 

’ export -type-data ,  ’ boolean) } 

var  lAID-GATE-OBJ-COEFFICIEHTS  :  map(HAHD-GATE-OBJ,  set(name-value-obj)) 
comput  ed-us  ing 

lAHD-GATE-OBJ-COEFFIClEITS(x)  =  {} 

var  lAID-GATE-OBJ-UPDATE-FUHCTIOH  :  map(HAHD-GATE-OBJ ,  symbol) 
comput  ed-us ing 

lAID-GATE-OBJ-UPDATE-FUICTIOI(x)  =  ’lAHD-GATE-OBJ-UPDATEl 
%  Other  Attributes; 

var  lAID-GATE-OBJ-DELAY  :  map(HAHD-GATE-OBJ,  integer) 
comput  ed-us ing 
lAID-GATE-OBJ-DELAY(x)  =  0 

-'ar  lAID-GATE-OBJ-MAHUFACTURER  :  map(IAHD-GATE-OBJ,  string) 
comput  ed-us ing 
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lAID-GATE-OBJ-MAlITJFACTURER(x)  = 


•I  11 


var  lAID-GATE-OBJ-HIL-SPEC?  :  map(HAID-GATE-OBJ.  boolean) 
comput  ed-us ing 

IAID-GATE-OBJ-MIL-SPEC?(x)  =  nil 

var  lAID-GATE-OBJ-POWER-LEVEL  ;  map{HAID-GATE-OBJ.  real) 
comput  ed-us ing 

lAID-GATE-OBJ-POWER-LEVEL(x)  =0.0 

form  Nake-HAID-GATE-lames-Unique 
unique-names-class ( ’lAID-GATE-QBJ ,  true) 

54 - 

function  lAID-GATE-OBJ-UPDATEl  (subsystem  ;  subsystem-obj , 

nand-gate  :  MAMD-GATE-OBJ)  = 

format  (debug-on,  "lAID-GATE-OBJ-UPDATE  on  *s'5i*',  naffle(nand-gate)) ; 

let  (ini  :  boolean  =  get-import ('ini,  subsystem,  nand-gate), 
in2  :  boolean  =  get-import (’ in2 ,  subsystem,  nand-gate)) 

set-export (subsystem,  nand-gate,  'outl,  '(ini  A  in2)) 

54 - 

function  lAID-GATE-OBJ-IEtf-UPDATE  (subsystem  :  subsystem-obj , 

nand-gate  :  lAHD-GATE-OBJ)  = 

format(t,  "HAID-GATE-OBJ-IEW-UPDATE  on  's'%'',  name (nand-gate)) 


E.4  Nor-Gate 


1 1  in-package ("RU") 
!!  in-grammar (’user) 


V,y.  File  name:  nor-gate.re 

var  lOR-GATE-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  lOR-GATE-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{set-attrs  (make-object ( ’import-obj) , 

' import-name ,  ' ini , 

'import-category,  'signal., 

' import -type-data,  'boolean) , 

set-attrs  (make-ob j  ect ( ' import-obj ) , 

' import -name ,  'in2, 

'import-category,  'signal, 
'import-type-data,  ’boolezm)} 
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var  HOR-GATE-OBJ-OUTPUT-DATA  :  8et(«xport-obj)  = 

{set-attrs  (make-object ( 'export -obj) , 

' export -name ,  ' out 1 , 

'export-category,  'signetL, 

'export-type-data,  'booleein)> 

var  lOR-GATE-OBJ-COEFFICIEITS  :  map(MOR-GATE-OBJ,  set(name-value-obj)) 
comput  ed-us  ing 

lOR-GATE-OBJ-COEFFICIEHTS(x)  =  {> 

var  lOR-GATE-OBJ-UPDATE-FUHCTIOI  ;  map(IOR-GATE-OBJ,  symbol) 
comput  ed-us ing 

lOR-GATE-OBJ-aPDATE-FUICTIQH(x)  =  'lOR-GATE-OBJ-UPDATEl 
*/,  Other  Attributes: 

var  lOR-GATE-OBJ-DELAY  :  map(IOR-GATE-OBJ.  integer) 
comput  ed-us  ing 
lOR-GATE-OBJ-DELAY(x)  =  0 

var  lOR-GATE-OBJ-MAIUFACTURER  :  map(IOR-GATE-OBJ ,  string) 
computed-us ing 

lOR-GATE-OBJ-MAIUFACTURER(x)  =  "  " 

var  lOR-GATE-QBJ-MIL-SPEC?  :  map(IOR-GATE-OBJ,  boolean) 
computed-us ing 

IOR-GATE-OBJ-mL-SPEC?(x)  =  nil 

var  lOR-GATE-OBJ-POWER-LEVEL  :  map(IOR-GATE-OBJ,  real) 
comput  ed-us  ing 

lOR-GATE-OBJ-POWER-LEVEL(x)  =0.0 

form  Make-IOR-GATE-Iames-Unique 
unique-names-class ( 'lOR-GATE-OBJ ,  true) 

% - 

function  lOR-GATE-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

nor-gate  :  lOR-GATE-OBJ)  = 


format(debug-on,  "lOR-GATE-OBJ-UPDATE  on  name(nor-gato)) ; 

let  (ini  :  boolean  =  get-import ('ini,  subsystem,  nor-gate), 
in2  :  boolean  =  get-import ('in2,  subsystem,  nor-gate)) 

set-export(sub8ystem,  nor-gate,  'outl,  "(ini  or  in2)) 

jj - 

function  lOR-GATE-OBJ-IEW-UPDATE  (subsystem  :  subsystem-obj , 

nor-gate  :  HDR-GATE-OBJ)  = 


format(t,  "lOR-GATE-OBJ-IEW-UPDATE  on  's'*/,",  name  (nor-gate)) 


E.5  Not- Gate 


M  in-package  ("RO") 

! !  in-grajnmar(  'user) 


Vl%  File  name:  not-gate.re 

var  lOT-GATE-OBJ  :  object-class  subtype-ol  Primitive-Obj 

var  lOT-GATE-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{ set-attrs  (make-ob j  ect ( ’ import-ob j ) , 

' import -name ,  '  ini , 

'import-category,  'signaJ., 

'import-tjrpe-data,  'boolecui)}- 

var  lOT-GATE-OBJ-OUTPUT-DATA  :  set(axport-obj)  = 

{set-attrs  (make-ob j  ect ( ' export-obj ) , 

' export -name ,  'outl, 

'export-category,  'signal, 

' export-type-data,  'boolean) } 

var  lOT-GATE-OBJ-COEFFICIEITS  :  map(IOT-GATE-OB J ,  set(name-value-obj)) 
computed-using 

lOT-GATE-OBJ-COEFFICIEITS(x)  *  {> 


var  lOT-GATE-OBJ-UPDATE-FUICTIOI  :  map(IOT-GATE-OB J ,  symbol) 
computed-using 

lOT-GATE-OBJ-UPDATE-FOICTIOKx)  =  'lOT-GATE-OBJ-UPDATEl 
'/,  Other  Attributes: 

var  lOT-GATE-OBJ-DELAY  :  map(IOT-GATE-OBJ,  integer) 
comput  ed-us ing 

lOT-GATE-OBJ-DELAY(x)  =  0 

var  lOT-GATE-OBJ-MAIUFACTURER  :  map(IOT-GATE-OBJ,  string) 
computed-using 

■OT-GATE-OBJ-IUIUFACTURER(x)  =  "  '* 

var  lOT-GATE-OBJ-MIL-SPEC?  :  map(IOT-GATE-OBJ,  boolean) 
computed-using 

10T-GATE-0BJ-MIL-SPEC?(x)  =  nil 

var  lOT-GATE-OBJ-POWER-LEVEL  :  map(IOT-GATE-OBJ,  real) 
comput  ed-us  ing 

lOT-GATE-OBJ-POWER-LEVEL(x)  =0.0 

form  Make-IOT-GATE-Rames-Unique 
unique-names-class ( ' ROT-GATE-OB J ,  true) 
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y. 

function  lOT-GATE-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

not-gate  :  lOT-GATE-OBJ)  = 

format (debug-on,  "lOT-GATE-OBJ-UPDATE  on  "s'X'',  name(not-gate)) ; 

let  (ini  :  boolean  =  get-import (* ini ,  subsystem,  not-gate)) 

set-ezport(subsystem,  not-gate,  ’outl,  '(ini)) 

% - 

function  lOT-GATE-OBJ-IEE-UPDATE  (subsystem  :  subsystem-obj , 

not-gate  :  lOT-GATE-OBJ)  = 

format (t,  "lOT-GATE-OBJ-IEW-UPDATE  on  's'^*',  name (not-gate)) 


E.6  JK-FHp-Flop 

! !  in-package (“RU") 

!!  in-grammar( ’user) 

%%  File  name:  jk-f lip-flop. re 

var  JK-FLIP-FLOP-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  JK-FLIP-FLOP-OBJ-IIPUT-DATA  :  set(import-obj)  = 

■{set-attrs  (make-ob j  ect  ( ’  import-ob j  ) , 

’ import-name ,  ’ J , 

’import-category,  ’signal, 

’import-type-data,  ’boolean), 
set-attrs  (make-obj  ect ( ’ import-obj ) , 

’ import -name ,  ’K, 

’import-category,  ’signal, 

’import -type-data,  ’boolean), 
set-attrs  (make-obj  ect ( ’ import-obj ) , 

’import-name,  'Clk, 

’import-category,  ’signed., 

’import -type-data,  ’boolean)} 

var  JK-FLIP-FLOP-OBJ-OUTPUT-DATA  :  oet(export-obj)  = 

{set-attrs  (make-obj  ect ( ’ export -obj ) , 

’ export -name ,  ’ Q , 

’export-category,  ’signed, 

’export-type-data,  ’boolean), 
set-attrs  (make-obj ect ( ’ export-obj ) , 

'export-name,  'Q-Bar, 

’export-category,  ’sign2Q., 

’ export -t3rpe-data,  ’boolean)} 
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var  JK-FLIP-FLOP-OBJ-COEFFICIEITS  :  iiiap( JK-FLIP-FLOP-OBJ .  set(naine-value-obj)) 
comput  ed-as ing 

JK-FLIP-FLOP-OBJ-COEFFICIEITS(i)  =  O 

var  JK-FLIP-FLOP-OBJ-UPDATE-FUICTIOI  :  map( JK-FLIP-FLOP-OBJ,  symbol) 
comput  ed-us ing 

JK-FLIP-FLOP-OBJ-UPDATE-FUICTIOI(x)  =  * JK-FLIP-FLOP-OB J-UPDATEl 
%  Other  Attributes: 

var  JK-FLIP-FLOP-OB J-DELAY  :  map( JK-FLIP-FLOP-OBJ,  integer) 
computed-using 

JK-FLIP-FLOP-OB J-DELAY (x)  =  0 

var  JK-FLIP-FLOP-OBJ-MAIUFACTURER  :  map( JK-FLIP-FLOP-OBJ ,  string) 
comput  ed-us ing 

JK-FLIP-FLOP-OBJ-MAlUFACTURER(x)  =  "  “ 

var  JK-FLIP-FLOP-OB J-MIL-SPEC?  :  map (JK-FLIP-FLOP-OBJ,  boolean) 
comput  ed-us ing 

JK-FLIP-FLOP-OB J-MIL-SPEC? (x)  =  nil 

var  JK-FLIP-FLOP-OBJ-POWER-LEVEL  :  map (JK-FLIP-FLOP-OBJ,  real) 
computed-using 

JK-FLIP-FLOP-OB J-POWER-LEVEL(x)  =0.0 

var  JK-FLIP-FLOP-OB J-SET-UP-DEUY  :  map( JK-FLIP-FLOP-OBJ,  integer) 
computed-us ing 

JK-FLIP-FLOP-OBJ-SET-UP-DELAY(x)  =  0 

var  JK-FLIP-FLOP-OB J-HOLD-DELAY  :  map( JK-FLIP-FLOP-OBJ,  real) 
comput  ed-us ing 

JK-FLIP-FLOP-OB J-HOLD-DELAY (x)  =0.0 

var  JK-FLIP-FLOP-OBJ-STATE  :  map( JK-FLIP-FLOP-OBJ,  boolean) 
computed-using 

JK-FLIP-FLOP-OBJ-STATE(x)  =  nil 


lorm  Make-JK-FLIP-FLOP-Iames-Unique 
unique-names-class ( ’ JK-FLIP-FLOP-OBJ ,  true) 

X - 

function  JK-FLIP-FLOP-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

jk-flip-flop  :  JK-FLIP-FLOP-OBJ)  = 

format (debug-on,  " JK-FLIP-FLOP-OB J-UPDATE  on  "B'y,",  name( jk-flip-flop)) ; 
let  (j  :  boolean  =  get-import(’J,  subsystem,  jk-flip-flop). 
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k  :  boolean  =  get-iiiiport('K,  subsystea,  jk-llip-flop) , 
elk  :  booleem  =  get-import ( 'Clk,  subsystem,  jk-llip-flop)) 


(if  'j  k  k  k  elk  then 

JK-FLIP-FLOP-OBJ-STATE(jk-flip-llop)  <-  nil 

elseif  j  k  k  k  elk  then 

JK-FLIP-FLOP-OBJ-STATE(jk-llip-flop)  <- 

-JK-FLIP-FLOP-OBJ-STATE(jk-flip-flop) 
elseil  j  k  'k  k  elk  then 

JK-FLIP-FLOP-QBJ-STATE(jk-flip-flop)  <-  true 

); 

set-ezport(subsystem,  jk-llip-llop,  'Q, 

JK-FLIP-FLOP-OB J-STATE( jk-llip-llop) ) ; 
set-exportCsubsystem,  jk-llip-flop,  ’Q-Bar, 

* JK-FLIP-FLOP-OB J-STATE(jk-f lip-flop) ) 

% - 

function  JK-FLIP-FLOP-OBJ-IEM-UPDATE  (subsystem  :  subsystem-obj . 

jk-f lip-flop  :  JK-FLIP-FLOP-OB J)  = 

formatCt,  " JK-FLIP-FLOP-OB J-IEW-UPDATE  on  -s*y.",  name( jk-f lip-1 lop)) 


E.  7  svjitch 


!!  in-package  C'RO") 

!!  in-grammar('u8er) 

%%  File  name:  smitch.re 

var  SWITCH-OBJ  :  object-class  subtype-ol  Primitive-Obj 

var  SWITCH-OBJ-IIPUT-DATA  :  set(import-obj)  =  {} 

var  SWITCH-OBJ-OUTPUT-DATA  :  8et(export-obj)  = 

■Cset-attrs  (make-ob j  ect ( ' export-ob j ) , 

’ export -name ,  'outl, 

’export-category,  ’sign2d., 

’export-type-data,  ’boolean)} 

var  SWITCH-OBJ-COEFFICIEITS  :  map(SHITCH-OBJ,  set(name-value-obj)) 
computed-us ing 

SWITCH-OBJ-COEFFICIEITS(x)  =  {} 

var  SWITCH-OBJ-OPDATE-FUICTIOI  :  map(SHITCH-OBJ ,  symbol) 
computed-us ing 
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S¥ITCH-OBJ-OPDATE-FUICTIOI(x)  =  'SWITCH-OBJ-UPDATEl 


X  Other  Attributes: 

var  SWITCH-OBJ-MAIUFACTURER  :  map(S«ITCH-OBJ,  string) 
coaput  ed-us ing 

SWITCH-OBJ-MAIOFACTiniER(x)  =  •'  “ 

var  SVITCH-OBJ-DEBOUICED  :  map(SVITCH-OBJ.  boolean) 
computed-using 

SHITCH-OBJ-DEBOUICED(x)  =  nil 

var  SWITCH-OBJ-DELAY  :  map(SWITCH-OBJ .  integer) 
co^>nted-using 
SMITCH-OBJ-DELAY(x)  =  0 

var  SWITCH-OBJ-POSITIOI  :  mapCSVITCH-OBJ,  symbol) 
coaputed-us ing 
SWITCH-OBJ-POSITIOI (x)  =  'on 

fora  Make-SVITCH-laaes-Unique 
unique-naaes-class( 'SVITCH-OBJ,  true) 

% - 

function  SVITCH-OBJ-UPDATEl  (subsystem  :  subsystea-obj , 

suitch  :  SUITCH-OBJ)  = 

format (debug-on,  "SHITCH-GATE-OBJ-OPDATE  on  *8"X",  name(suitch)) ; 

let  (signal  :  boolean  =  nil) 

(if  SWITCH-OBJ-POSITIOKsuitch)  =  '01  then 
signal  <-  true 

): 

set-export (subsystem,  switch,  'outl,  signal) 

X - 

function  SHITCH-OBJ-IEV-UPDATE  (subsystem  :  subsystea-obj , 

switch  :  SVITCH-OBJ)  = 

foraat(t,  "SWITCH-OBJ-IEW-UPDATE  on  "s'X",  naae(8witch)) 


E.8  LED 

n  in-package("BO") 
!!  in-grammar ('user) 


E-ll 


File  name : 


led. re 


var  LED-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  LED-OBJ-IIPOT-DATA  ;  aet(import-obj)  = 

{ set-attrs  (make-ob j  act ( ' import-ob j ) , 

•  import-name ,  ‘ ini > 

'import-category,  'signal, 

'import -type-data,  'boolean)} 

var  LED-OBJ-OUTPUT-DATA  :  8et(export-obj)  =  {} 

var  LED-OBJ-COEFFICIEITS  :  map(LED-OBJ,  setCname-value-obj)) 
computed-using 

LED-OBJ-COEFFICIEITS (x)  *  {} 


var  LED-OBJ-UPDATE-FOICTIOI  :  map (LED-OBJ,  symbol) 
compnted-using 

LED-OBJ-UPDATE-FOICTIOI (x)  =  'LED-OBJ-OI-QFF-UPDATE 
%  Other  Attributes: 

var  LED-OBJ-NAIUFACTURER  :  map(LED-OBJ,  string) 
compnted-using 

LED-OBJ-MAIOFACTURER(x)  =  "  ” 

var  LED-OBJ-COLOR  :  map(LED-OBJ,  symbol) 
computed-using 
LED-OBJ-COLOR(x)  =  'red 

form  Nake-LED-Iames-Unique 
unique-names-class ( 'LED-OBJ ,  true) 


X - 

function  LED-OBJ-OI-OFF-UPDATE  (subsystem  :  subsystem-obj , 

led  :  LED-OBJ)  = 

format (debug-on,  "LED-OBJ-OI-OFF-UPDATE  on  "s'X",  name (led)); 

let  (display-v2Q.ue  :  symbol  =  'off) 

(if  get-import ('ini,  subsystem,  led)  then 
display-value  <-  ' on 

); 

format(t,  "LED  's  =  's'X",  name(led),  display-value) 

X - 

function  LED-OBJ-T-F-UPDATE  (subsystem  :  subsystem-obj , 

led  :  LED-OBJ)  = 

format (debug-on,  "LED-OBJ-T-F-UPDATE  on  *s"%",  name(led)): 
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let  (display-va^.ue  :  symbol  =  ’false) 

(if  get-import (’ini,  subsystem,  led)  then 
display-value  <-  ’true 

): 

format(t,  "LED  ~s  =  ‘a'X",  name(led),  display-value) 


E.9  Counter 


?!  in-package ("RU") 
I!  in-grammar( ’user) 


%%  File  name:  counter. re 

var  COUITER-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  COUITER-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{set-attrs  (make-ob j ect ( ’ import-ob j ) , 

’import-name,  ’clock, 

’import-category,  ’signal, 

’ import-type-data,  ’boolean) , 

set-attrs  (make-obj  ect ( ’ import-obj ) , 

’ import -name ,  ’ reset , 

’import -category,  ’signal, 

’import -type-data,  ’boolean)} 

var  COUITER-OBJ-OUTPUT-DATA  :  s et( export -obj)  = 

{set-attrs  (make-obj  ect ( ’ export-ob j ) , 

’ export -name ,  ’Isb, 

’export -category,  ’signal, 
’export-type-data,  ’boolean), 

set-attrs  (make-obj ect ( ’ export-obj ) , 

’ export-name ,  ’ msb , 

’export-category,  ’signal, 
’export-type-data,  ’boolsM)} 


var  COUITER-OBJ-COEFFICIEITS  :  map (COUITER-OBJ,  set(name-value-obj)) 
comput  ed-us ing 

COUITER-OBJ-COEFFICIEITS(x)  = 

{set-attrs  (make-object(’name-valne-obj),  ’name- value-name,  ’max-count, 

’name- value- value,  3)} 
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var  COUHTER-OBJ-UPDATE-FUKCTIOI  :  map(COUlTER-OBJ ,  symbol) 
comput  ed-us ing 

COUITER-OBJ-UPDATE-FUICTIOI(x)  =  'COUITER-OBJ-UPDATEl 


y,  other  Attributes: 


var  COUITER-OBJ-COUIT  : 
comput  ed-us  ing 
COUITER-OBJ-COUBT(x) 

var  COUITER-OBJ-DELAY  : 
comput  ed-us  ing 
COUITER-OBJ-DELAY(x) 


map(COUITER-OBJ. 
=  0 

map(COURTER-QBJ. 
=  0 


integer) 


integer) 


var  COUITEB-OBJ-MAIUFACTURER  :  map(CQUITER-OBJ,  string) 
computed-using 

COUITER-OBJ-MAIUFACTURER(x)  =  "  " 

var  COOITER-OBJ-MIL-SPEC?  :  map(COUITER-OBJ,  boolean) 
comput  ed-us  ing 

COUITER-OBJ-MIL-SPEC?(x)  =  nil 

var  COUITER-OBJ-POWER-LEVEL  :  map(COUlTER-OBJ,  real) 
comput  ed-us  ing 

COUlTER-OBJ-POWER-LEVEL(x)  =0.0 


form  Nake-COUITER-lames-Unique 
unique-names-class ( ’ COUITER-OB J ,  true) 


51 - 

function  COUITER-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

counter  :  COUITER-OB J)  = 

format (debug-on,  "COUITER-OBJ-UPDATEl  on  *s"%",  naffle(counter)) ; 

let  (clock  :  boolean  =  get- import ( 'clock,  subsystem,  counter), 
reset  :  boolean  =  get-import ('reset,  subsystem,  counter)) 

(if  reset  then 

COUITER-OBJ-COUIT(counter)  <-  0 
elseif  clock  then 

CODITER-OBJ-COUIT(counter)  <-  COUITER-OBJ-COUIT(counter)  +1 

): 

(if  CODITER-OBJ-COUIT(counter)  > 

get-coefficient-value(co\uter,  'max-count)  then 
COUITER-OBJ-COUIT (counter)  <-  0 

); 

if  COUITER-OB J-C0UIT( counter)  =  0  then 

set-export (subsystem,  counter,  'msb,  nil); 
set-export(subsystem,  counter,  'Isb,  nil) 
elseif  COUITER-OB J-COUIT(counter)  =  1  then 
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set-export (subsystem,  counter,  ’msb,  nil); 
set-export(subsystem,  counter,  'Isb,  true) 
elseif  COUITER-OBJ-COUIT(counter)  =  2  then 
set-ezport(subsysteffl,  counter,  'msb,  true); 
set-export (subsystem,  counter,  'Isb,  nil) 
elseif  COUVTER-OBJ-COUHT(counter)  =  3  then 
set-export (subsystem,  counter,  *msb,  true); 
set-export (subsystem,  counter,  'Isb,  true) 


E.IO  Half- Adder 


!  !  in-package ("RU") 
!!  in-grammar ('user) 


%%  File  name:  half -adder. re 

var  HALF-ADDER-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  HALF-ADDER-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{set-attrs  (make-ob j ect ( ' import-ob j ) , 

'import-name,  'ini, 

'import-category,  'signal, 

' import -tjrpe-data,  'boolean), 

set-attrs  (make-ob j  ect ( ' import-obj ) , 

'import-name,  ’in2, 

'import-category,  'signeil, 

' import-type-data,  'boolean)> 


var  HALF-ADDER-OBJ-OUTPUT-DATA  :  set(export-obj)  = 

{set-attrs  (make-ob j  ect ( ' export-ob j ) , 

' export-name ,  ' s , 

'export -category,  'signal, 

'export -type-data,  'boolean), 
set-attrs  (make-ob j  ect ( ' export-ob j ) , 

’ export -name ,  'c, 

'export-category,  'signal, 

'export-type-data,  'boolean)} 

vai  HALF-ADDER-OBJ-COEFFICIEITS  :  map(HALF-ADDER-OBJ,  set(name-value-obj)) 
comput  ed-us ing 

HALF-ADDER-OBJ-COEFFICIEITS (x)  =  {> 


var  HALF-ADDER-OBJ-UPDATE-FUICTIOI  :  map(HALF-ADDER-OB J ,  symbol) 
computed-us ing 
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HlLF-ADDER-OBJ-UPDATE-FUHCTIOI(x)  =  ’HALF-ADDER-OBJ-UPDATEl 
%  Other  Attributes: 

var  HALF-ADDER-PJJ-DELAY  :  map (HALF- ADDER-OBJ,  integer) 
comput  ed-us  ing 

HALF-ADDER-OBJ-DELAY(x)  =  0 

var  HALF-ADDER-OBJ-MAIUFACTURER  :  map(HALF-ADDER-OBJ,  string) 
comput  ed-us  ing 

HALF-ADDER-OBJ-MAIUFACTURERCx)  =  “  " 

var  HALF-ADDER-OBJ-MIL-SPEC?  :  map(HALF-ADDER-OBJ,  boolean) 
comput  ed-us ing 

HALF-ADDER-OBJ-MIL-SPEC? (x)  =  nil 

var  HALF-ADDER-OBJ-POWER-LEVEL  :  map(HALF-ADDER-OBJ .  real) 
comput  ed-us  ing 

HALF-ADDER-OBJ-POHER-LEVEL(x)  =0.0 

form  Make-HALF-ADDER-Hames-Unique 
unique-names-class( ’HALF-ADDER-OBJ.  true) 


54 - 

function  HALF-ADDER-OBJ-OPDATEl  (subsystem  :  subsystem-obj , 

hall-adder  :  HALF-ADDER-OBJ)  = 


let  (ini  :  boolean  =  get-import('inl,  subsystem,  hall-adder), 
in2  :  boolean  =  get-import ( ’in2,  subsystem,  hall-adder)) 


il  'ini  and  *in2  then 


elseil  ini  and  'in2  then 


elseil 


elseil  ini  and  in2  then 


hall-adder , 

's. 

nil); 

hall -adder. 

’c. 

nil) 

L 

hall -adder. 

's. 

true) ; 

hall-adder , 

'c. 

nil) 

L 

hall -adder. 

’s. 

true) ; 

hall-adder , 

’c. 

nil) 

hall-adder , 

's. 

nil); 

hall-adder , 

'c. 

true) 

E.ll  Decoder 

! !  in-package ("RU") 
!!  in-grammar ( ’user) 
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'!!!,  File  name:  decoder. re 


var  DECODER-OBJ  :  object-class  subtype-ol  Primitive-Obj 

var  DECODER-OBJ-IHPUT-DATA  :  s et( import -obj)  = 

{set-attrs  (make-object( ’ import-obj) , 

' import -name ,  ’ ini , 

'import-category,  'signal, 

' import-type-data,  'boolean) , 

set-attrs  (make-object( ' import-obj) , 

' import -name ,  ' in2 , 

'import-category,  'signal, 

'  import-t3rpe-data,  'boolean) , 

set-attrs  (make-ob j  ect ( ' import-obj ) , 

' import -name ,  '  in3 , 

'import-category,  'signal, 

' import -t3rpe-data,  'boolean)} 

var  DECODER-QBJ-OUTPUT-DATA  :  sot(export-obj)  = 

{set-attrs  (make-object( ' export-obj) , 

' export -name ,  ’ mO , 

'export-category,  'signal, 
'export-type-data,  'boolean), 

set-attrs  (make-obj ect ( 'export-obj) , 

' export-name ,  ' ml , 

'export-category,  'signal, 
'export-type-data,  'boolean), 

set-attrs  (make-object ( 'export-obj) , 

'export-name,  'm2, 

'export-category,  'signal, 

' export -t3fpe-data,  'boolean), 

set-attrs  (medce-obj ect ( 'export-obj ) , 

'export-name,  ’m3, 

'export-category,  'signaJ., 
'export-type-data,  ’booleam), 

set-attrs  (make-object ( 'export-obj) , 

' export -name ,  ’m4, 

'export-category,  'signal, 
'export-type-data,  ’boolean), 

set-attrs  (make-obj ect ( 'export-obj) , 

’ export-name ,  'm6 , 

'export-category,  'signal, 
'export-type-data,  'boolean). 


set-attrs  (nake-obj ect ( ' export -obj ) , 

'export-name,  ’m6, 

'export-category,  'signad., 

' export-type-data ,  ' boolean) , 

set-attrs  (make-object( 'export-obj) , 

'export-name,  ’m7, 

'export- category,  'signal, 

'export -type-data,  'boolean)} 

var  DECODER-OBJ-COEFFICIEHTS  :  map(DECODER-DBJ,  set(name-value-obj)) 
comput  ed-us ing 

DECODER-OBJ-COEFFICIEHTS (x)  =  O 

var  DECODER-OBJ-UPDATE-FUHCTIOH  :  map(DECODER-OBJ,  symbol) 
comput  ed-us  ing 

DECODER-OBJ-UPDATE-FUHCTIOI(x)  =  'DECODER-OBJ-UPDATEl 
y.  Other  Attributes: 

var  DECODER-OBJ-DELAY  :  map(DECODER-OBJ,  integer) 
computed-us ing 
DECODER-OBJ-DELAY(x)  =  0 

var  DECODER-OBJ-MAIUFACTURER  :  map(DECODER-OBJ,  string) 
comput ed-us ing 

DECODER-OBJ-HAIUFACTUBER(x)  =  "  " 

var  DECODER-OBJ-HIL-SPEC?  :  map(DECODER-OBJ,  boolean) 
comput  ed-us ing 

DECODER-OBJ-MIL-SPEC?(x)  =  nil 

var  DECODER-OBJ-POHER-LEVEL  :  map(DECODER-OBJ,  real) 
computed-us ing 

DECODER-OBJ-POWER-LEVEL(x)  =0.0 

form  Nake-DECODER-Iames-Unique 
unique-names-classC 'DECODER-OBJ ,  true) 


% - 

function  DECODER-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

decoder  :  DECODER-OBJ)  = 

let  (x  :  boolean  =  get-import ( 'ini ,  subsystem,  decoder), 
y  :  boolean  =  get-import ( 'in2,  subsystem,  decoder), 
z  :  boolean  =  get-import (' in3 ,  subsystem,  decoder)) 

y,  set  all  outputs  to  false  to  start;  don't  want  any  left-over 
%  values  adversely  affecting  output. 

8et-ezport(8Ubsystem,  decoder,  'mO,  nil); 
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set-export (subsystem,  decoder,  'ml,  nil); 
set-export(sabsystem,  decoder,  'm2,  nil); 
set-export(subsystem,  decoder,  'm3,  nil); 
set-export(sabsystem,  decoder,  'm4,  nil); 
set-export(subsystem,  decoder,  'mS,  nil); 
set-export (subsystem,  decoder,  'm6,  nil); 
set-export (subsystem,  decoder,  ‘ml,  nil); 

if  "x  and  'y  and  "z  tben 

set-export(subsystem,  decoder,  'mO,  true) 
elseif  ~x  and  'y  and  z  then 

set-export(subsystem,  decoder,  'ml,  true) 
elseif  'x  and  y  and  ~z  then 

set-export(subsystem,  decoder,  'm2,  true) 
elseif  'x  and  y  and  z  then 

set-export (subsystem,  decoder,  'm3,  true) 
elseif  X  and  ~j  and  ~z  then 
set-export (subsystem,  decoder,  'm4,  true) 
elseif  X  and  'y  and  z  then 

set-export(subsystem,  decoder,  'mS,  true) 
elseif  X  and  y  and  *z  then 

set-export (subsystem,  decoder,  'm6,  true) 
elseif  X  and  y  and  z  then 

set-export (subsystem,  decoder,  'm7,  true) 


E.12  MUX 

I !  in-package ("RU") 
i!  in-grammar('user) 


%%  File  name:  mux. re 

var  MUX-OBJ  :  object-class  subtype-of  Primitive-Obj 

var  MUX-OBJ-IIPUT-DATA  :  set(import-obj)  = 

{ set-attrs  (make-ob j  ect ( ' import-ob j ) , 

' import-name ,  ' inO , 

'import-category,  'signal, 
'import-type-data,  'boolean), 

set-attrs  (make-object( 'import-obj) , 

' import-name ,  '  ini , 

'import-category,  'signed, 

'import -type-data,  'boolean), 

(make-ob j  ect ( ' import-obj ) , 

' import-name ,  ' in2 , 

'import-category,  'signal. 


set-attrs 


'import -type-data,  'boolean). 


set-attrs  (make-ob j  ect ( ' import-obj ) , 

' import -name ,  ' in3 , 

'import-category,  'signal, 

' import -type-data,  'boolean) , 

set-attrs  (make-obj  ect ( ' import-obj ) , 

' import -name ,  'sO, 

'import-category,  'signal, 
'import-type-data,  'booleem) , 

set-attrs  (make-obj ect ( 'import-obj) , 

' import -name ,  'si, 

'import-category,  'signed, 

'import -type-data,  'boolean)} 

var  MUX-OBJ-OUTPUT-DATA  :  set(eiport-obj)  = 

{set-attrs  (make-obj ect (' export-obj ) , 

' export-name ,  ' outl , 

'export-category,  'signal, 

'export -type-data,  'boolean)} 

var  MUX-OBJ-COEFFICIEITS  :  map(HUX-OBJ,  aet(name-value-obj)) 
comput  ed-ns ing 
MUX-OBJ-COEFFICIEITS(x)  =  {} 


var  MUX-OBJ-OPDATE-FUICTIOI  :  map(HUX-OBJ,  symbol) 
computed-using 

MUX-OBJ-UPDATE-FUICTIOKx)  =  'HUX-OBJ-OPDATEl 
X  Other  Attributes: 

var  HUX-OBJ-DELAY  :  map(lfUX-OBJ,  integer) 
comput  ed-us ing 
ItUX-OBJ-DELAY(x)  =  0 

var  MOX-OBJ-MAIUFACTURER  :  map(MUX-OBJ,  string) 
comput  ed-us ing 

MOX-OBJ-MAIUFACTUHER(x)  =  "  " 

var  MOX-OBJ-MIL-SPEC?  :  map(IfUX-OBJ,  boolean) 
comput  ed-us ing 
MOX-OBJ-MIL-SPEC? (x)  =  nil 

var  MOX-OBJ-POWER-LEVEL  :  map(MUX-OBJ,  real) 
comput  ed-us ing 
MUX-OBJ-POWER-LEVEL(x)  =0.0 

Yorm  Make-MUX-Iames-lhiique 
unique-names-cla88('MUX-0BJ,  true) 


E-20 


A - 

function  MUX-OBJ-UPDATEl  (subsystem  :  subsystem-obj , 

mux  :  MUX-OBJ)  = 

let  (sO  :  boolean  =  get-import (’sO,  subsystem,  mux), 
si  :  boolean  =  get-importC’sl,  subsystem,  mux)) 

if  'sO  and  'si  then 

set-export(subsystem,  mux,  'outl, 

get-import (’ inO ,  subsystem,  mux)) 
elseif  sO  and  'si  then 

set-export(subsystem,  mux,  ’outl, 

get-import (’ ini ,  subsystem,  mux)) 
elseif  'sO  and  si  then 

set-export (subsystem,  mux,  'outl, 

get-import(’in2,  subsystem,  mux)) 
elseif  sO  and  si  then 

set-export (subsystem,  mux,  ’outl, 

get-import (’ in3 ,  subsystem,  mux)) 
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